Use `float` instead of `Date` for protocol types for higher precision

[bruno-garcia]

• If possible add an overload to with float but keep the Date one
• add backward compatibility when deserializing payloads

The goal is to have a higher precision in the performance product in particular. So types such as Span and Transaction should have float but it's less of a concern to something like Breadcrumb

[bruno-garcia]

@denrase we're hoping we can fit this change on the next major that'll include the new JSON serialization code.

[maciejwalkowiak]

float or long?

[marandaneto]

float or double I guess, see DateUtils.getDateTimeWithMillisPrecision, we have to support the type eg 1581410911.988123456

[maciejwalkowiak]

Even if we change the type to double or float, we are still unable to retrieve current timestamp from the system with precision greater than milliseconds - which happens when span/transaction is started or finished. Please elaborate on this feature - why do we need it, how it will be used.

[bruno-garcia]

I was under the impression that both Spring and Android have an alternative with high precision but none that could be shared between both them so we would need to put it behind some abstraction and swap the standard date providers by the high precision ones in sentry-android-core and others that apply.

[maciejwalkowiak]

Java 9+ has an option for higher precision. For Java 8 AFAIK there is nothing like that for any framework just because JVM does not provide this option.

In regards to Android - I see there are java.time classes added in API 26. Is there anything that provides microseconds+ time precision with the API level we support? @marandaneto

[marandaneto]

we cant rely on Android API >= 26, the only alternative I see is System.nanoTime(), its not the current Date and Time but rather a time interval, can we extract the precision from this var and add to the ISO8601 format?

See https://dev.to/pyricau/android-vitals-what-time-is-it-2oih

[maciejwalkowiak]

This would mean that span start time has always milliseconds precision and end time microseconds precision. Which would make it look clearly wrong.

How is it beneficial for users to have microseconds precision for spans?

I can implement it but please give a clear green light that we want to go this way.

[marandaneto]

what I meant is, the way how it is right now it'd not work using System.nanoTime() because our protocol requires a Date instead of an interval that we can measure locally.

I'm running out of ideas for back compatibility, maybe @bruno-garcia

[marandaneto]

https://www.threeten.org/threetenbp/ is a viable alternative, for Android, https://github.com/JakeWharton/ThreeTenABP which is based on threetenbp, but it's a transitive dependency/

not sure if there's more than millis precision though -> https://www.threeten.org/threetenbp/apidocs/org/threeten/bp/Instant.html

[marandaneto]

when doing this one, also consider #1513