Prometheus exporter should not set explicit timestamps

[dashpole]

Steps to reproduce

I saw second-hand that the prometheus exporter adds explicit timestamps, but don't have exact reproduction steps.

# TYPE grpc_client_attempt_started_ counter
grpc_client_attempt_started_{grpc_method="grpc.testing.TestService/UnaryCall",grpc_target="dns:///10.52.1.55:14285"} 10 1694819876572

The last number on the right is the start timestamp.

What is the expected behavior?
Metrics should not have explicit timestamps set. From the OpenMetrics specification

MetricPoints SHOULD NOT have explicit timestamps.

What is the actual behavior?

Explicit timestamps are added to prometheus metrics.

opentelemetry-cpp/exporters/prometheus/src/exporter_utils.cc

Line 265 in 0563a71

metric.timestamp_ms = time.count() / 1000000;

Additional context

In prometheus, the scrape time is used as the timestamp. Explicit timestamps can limit some functionality, such as compatibility with the prometheus push gateway, so they are generally not recommended.

[yashykt]

This was seen on gRPC C++'s OTel plugin, but the pattern of usage is nothing out of the ordinary from what I understand. Reference - https://github.com/grpc/grpc/blob/62521a889fe134859aed7bdf4ea0730534f15d09/src/cpp/ext/otel/otel_plugin.cc#L170

A Meter with the name "grpc" was created, and a counter instrument with the name "grpc.client.attempt.started" was created out of it.

The counter was incremented like so - https://github.com/grpc/grpc/blob/62521a889fe134859aed7bdf4ea0730534f15d09/src/cpp/ext/otel/otel_client_filter.cc#L122