Indeed it mentions it; but after careful reading there is no normative suggestion to actually adhere to it. (no SHOULD and definitely not a MUST, not even a RECOMMENDED).
They just say that to increase interoperability no more than 53 bits of integer precision should be assumed without making a clear normative decision about it. The only normative part in that section is that numbers consist of an integer part and a fractional part.
They also say that implementations are allowed to set any limits on the range and precision of numbers accepted.
So yeah Lennart seems to be technically correct. Even when reading the RFC by the letter.
On Thu, Oct 28, 2021 at 9:21 AM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> Arian van Putten <arian.vanputten@xxxxxxxxx> schrieb am 26.10.2021 um 10:41 in
Nachricht
<CAE0h1269nSwDOGJc9BKMRRc2dtVJXZVHNZkzCpCQFVddfYGvXQ@xxxxxxxxxxxxxx>:
> Hey list,
>
> I'm reading the https://systemd.io/USER_RECORD/ spec and I have a question
>
> There are some fields in the USER_RECORD spec which are described as
> "unsigned 64 bit integer values". Specifically the fields describing
> time.
>
> However JSON lacks integers and only has doubles [0]; which would mean 53
That's nonsense: JSON _has_ integers, but they are restricted (See: 6. Numbers in RFC 7159)
int = zero / ( digit1-9 *DIGIT )
That was some stupid design decision IMHO.
> bit integer precision is about the maximum we can reach. It's unclear to
The RFC mentions "IEEE 754-2008 binary64 (double precision) numbers"
> me from the spec whether I should use doubles to encode these fields or use
> strings. Would it be possible to further clarify it? If it is indeed a
> number literal; this means the maximum date we can encode is
> 9007199254740991 which corresponds to Tuesday, June 5, 2255 . This
> honestly is too soon in the future for my comfort. I suggest encoding 64
> bit integers as string literals instead to avoid the truncation problem.
>
> [0] https://datatracker.ietf.org/doc/html/rfc7159#section-6
