fix: precision for long dates

[johannes-vogel]

We are experimenting with the new data format versions (see #278) that the new version has included and stumbled over a bug that caused a precision loss. This PR includes the minimum fix for our tests to succeed.

The following value provided for a LONGDATE 2025-07-21T09:15:33.873Z results in a precision loss.

I also there's more improvement potential but that's for you to decide.

@IanMcCurdy FYI

[johannes-vogel]

Alternatively, one could split ts[6] by the dot and convert the parts to a number or even adapt the timestamp regexp.

[IanMcCurdy]

Hi Johannes, thanks for looking into this issue. I apologize for the delay in getting back to you, but the fix you've come up with looks valid to me - I'll put it through our internal review process and we'll get it submitted as soon as possible.

[johannes-vogel]

Hi Johannes, thanks for looking into this issue. I apologize for the delay in getting back to you, but the fix you've come up with looks valid to me - I'll put it through our internal review process and we'll get it submitted as soon as possible.

Please be aware, that this is sufficient for our usage since we have ms precision but values like '33.33333' are still prone to precision loss:

~~(('33.33333' * 10000000) % 10000000)
→ 3333299

[johannes-vogel]

I think that's fixed with 6506050