Fix usage of non JSON numeric values for time fractions (without having precision issues) #706
After reading all other discussions (and code for this PR) I have an impression there is no understanding on what's happening:
php's float64 (and literally every other's programming language implementation of IEEE754) fails to represent precisely more than 53 bits of significand precision.
This leads to "rounding" problem (which in fact is just lack of precision in the float64 ieee754 type, nothing really "rounds").
You cannot solve it in userland using built-in numeric types only.
What MUST be done though: date fields MUST be encoded as numbers, it should not even be an option, it's REQUIRED by the spec. Ideally, all changes that led to making the generated jwt non-complaint should be reverted, because there is no way or need to "fix" it, since it only broke everything even "worse".
What can be done if one wants precision over 53 bits of significand precision they need:
And once again: just shuffling
The problem with that "problem" is that it never was formalised: some arbitrary values were chosen as a "proof" of having the "issue" and then the "solution" was optimised to fit only that limited problem. If the library wants to solve the problem with "rounding" floats - then it should be first defined to what point. At this point it's not obvious why losing 18th significant digit is worse than losing 15th one.
If you read my old PR #702, the goal was to keep the 6 decimal digits same from a timestamp after encoding/decoding Json. If you think my solution has a problem or won't work, can you show me a case or example and explain why?
Im talking only about the 6 digits of timestamp and not talking about floats
Can you please explain what you mean by this?
Also what do you belive that can be changed to fix this "the bug is there and the referred PR is closed"
Your implementation would work, I just thought this: #618 (comment) was a problem.
Timestamp is encoded as a float.
@lcobucci I was kinda glancing over this earlier today, and I don't see massive problems with the patch itself. It seems fine code-wise, but I don't understand the rationale behind it: mostly lacking reference to issues connected to this. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/…
On Fri, Mar 19, 2021 at 7:14 PM Luís Cobucci ***@***.***> wrote: @Ocramius <https://github.com/Ocramius> would you also have a look at this, please? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#706 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFVEHHKPAFNCDBP5OWXF3TEOIBZANCNFSM4ZNZFXFQ> .
The RFC-7519 states that the `NumericDate` type is: > JSON numeric value representing the number of seconds from > 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring > leap seconds. Then also mentions that time fractions (as covered by RFC-3339) are supported: > Seconds Since the Epoch", in which each day is accounted for by > exactly 86400 seconds, other than that non-integer values can be > represented. While adding support for time fractions we've interpreted the "non-integer" really as any "non-integer" value, and used strings to guard against precision issues. That causes issues, since a string isn't a "JSON numeric value" according to the JSON specs. We observed that the 6-digit precision is not lost when doing JSON encode/decode operations, this applies that technique to make sure we comply to the specs and have "rounding issues" when dealing with floats.