Should HTTP duration metrics include bucket boundary of zero?

[trask]

Related question raised in #274 (comment)

Currently:

This metric SHOULD be specified with ExplicitBucketBoundaries of [ 0, 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10 ].

(https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-metrics.md#metric-httpserverrequestduration)

And the question is:

what is the point of having a boundary of 0 if we know the values we observe cannot be negative?

[trask]

it looks like @rapphil asked a similar question in open-telemetry/opentelemetry-specification#2759

The defaults for the explicit bucket histogram have the first boundary in the interval (-inf,0]. Since Explicit Bucket histograms only support non-negative values, this first boundary can only record the 0 value, which is not very useful in practice given that the defaults of the Explicit Bucket histogram are supposed to record latency values.

@reyang @jmacd it looks like you may have thought about this most recently in open-telemetry/opentelemetry-specification#2770, do you recall if the zero bucket/boundary was discussed? i'm wondering if the reason it was kept at that time was because of open-telemetry/opentelemetry-specification#2770 (comment):

here is my personal thinking: introducing more buckets is not a breaking change (it might cause more resource, which is fine), removing buckets (reducing the number of buckets) could be a breaking change since it drops the accuracy (which could cause existing alerts being unavailable/wrong).

which wouldn't necessarily apply to HTTP semconv default buckets since it's not (quite yet) stable