Clock drift issue when calling DateUtils#getDateTimeWithMillisPrecision

if using 1623849812.985 works correctly, when using 1623849812.985594 with higher precision in millis, there’s an issue when (seconds * 1000) + millis. I don’t recall RN SDK sending more than millis precision, so I’m not sure if we should fix the Android SDK or the RN SDK.

A simple workaround would be to cut off after 3 digits or make the right calculation

[jennmueng]

Sounds good, just a note that

1591533492.631631 to 2020-06-07T12:38:12.631Z or do we round to the nearest number? eg 2020-06-07T12:38:12.632Z.

In the grooming yesterday I think the team agreed to floor it, so it would be 1591533492.631631 to 2020-06-07T12:38:12.631Z, and 1591533492.999999 to 2020-06-07T12:38:12.999Z

[marandaneto]

ok so figured that out, JS timestamps could have up to 13 decimal places but we don’t need all of that, in Mobile, up to 3 digits is already fine.

Example: 1591533492.631 should be formated to 2020-06-07T12:38:12.631Z 1591533492.63 to 2020-06-07T12:38:12.630Z or just 2020-06-07T12:38:12.63Z 1591533492.6 to 2020-06-07T12:38:12.600Z or just 2020-06-07T12:38:12.6Z 1591533492.631631 to 2020-06-07T12:38:12.631Z or do we round to the nearest number? eg 2020-06-07T12:38:12.632Z.

getDateTimeWithMillisPrecision method right now takes everything after the . assuming it’s only (or max.) 3 digits and sum it up, this causes a clock drift. we need to be sure that the number after the. eg 1591533492.631631631631 is formatted to millis in 3 digits so the calculation won’t be off.

Right now if I pass 1591533492.631631631, it converts to 2020-06-14T20:05:23.631Z instead of 2020-06-07T12:38:12.631Z which is obviously wrong.