Higher precision start timestamp for Spans

[adinauer]

Problem Statement

Spans are currently only ms precision but appear to be more precise due to being converted to a double. In the UI it looks like start_timestamp of a span is μs. This is caused by a number of things.

• Relay strips ns from the timestamp and uses μs instead (see https://github.com/getsentry/relay/blob/adbf8ff387285935553354c48ef04798c9a1c1ae/relay-general/src/protocol/types.rs#L965-L983).
• The Java SDK records the start timestamp as Date, then retrieves the millis via getTime() and then divides by 1000 (see

  sentry-java/sentry/src/main/java/io/sentry/protocol/SentrySpan.java

  Line 60 in b85d8aa

  this.startTimestamp = DateUtils.dateToSeconds(span.getStartTimestamp());

  )

Solution Brainstorm

We could create a DateProvider interface which has a now() method that returns the current timestamp as SentryDate. Then there could by different implementations:

• For older versions there could be one that keeps the current Date + System.nanoTime
• For Java 9+ and Android API 26+ we could use Instant

We could then allow passing in SentryDate when starting a span or when calling finish. For users who want to supply their own timestamps with high precision we could offer something like a SentryDoubleDate that just holds a double.

The SentryDate should also have a Double diff(SentryDate date) method that can calculate the difference using internals like the separate System.nanoTime that was collected.

[adinauer]

This will also be needed to make use of higher precision timestamps coming in from OpenTelemetry.

[adinauer]

For Android we will probably run into problems where we require compiler flags (coreLibraryDesugaringEnabled) and problems with older Android Gradle Plugins (< 4).

We need to make sure we don't break older versions. So sentry should behave as it currently is and other modules may add DateProviders that are able to provide more precision.

[dwd]

This would be really useful. My use-case is within Openfire - Openfire Github - and I've instrumented manually on this branch. The instrumentation works, but because this is an instant-messaging server, the transactions (XMPP Stanzas) are very fast, and ms-resolution causes the graph to look "skewed", with spans operating in parallel which are actually consecutive:

I'd assume that faster HTTP transactions would also show the same distortion.

[adinauer]

Thank you for sharing your use case @dwd, we'll update here when there's any news on this.