<div dir="ltr"><div>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).</div><div><br></div><div>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.</div><div><br></div><div>They also say that implementations are allowed to set any limits on the range and precision of numbers accepted.</div><div><br></div><div>So yeah Lennart seems to be technically correct. Even when reading the RFC by the letter.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 28, 2021 at 9:21 AM Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>> Arian van Putten <<a href="mailto:arian.vanputten@gmail.com" target="_blank">arian.vanputten@gmail.com</a>> schrieb am 26.10.2021 um 10:41 in<br>
Nachricht<br>
<<a href="mailto:CAE0h1269nSwDOGJc9BKMRRc2dtVJXZVHNZkzCpCQFVddfYGvXQ@mail.gmail.com" target="_blank">CAE0h1269nSwDOGJc9BKMRRc2dtVJXZVHNZkzCpCQFVddfYGvXQ@mail.gmail.com</a>>:<br>
> Hey list,<br>
> <br>
> I'm reading the <a href="https://systemd.io/USER_RECORD/" rel="noreferrer" target="_blank">https://systemd.io/USER_RECORD/</a> spec and I have a question<br>
> <br>
> There are some fields in the USER_RECORD spec which are described as<br>
> "unsigned 64 bit integer values".   Specifically the fields describing<br>
> time.<br>
> <br>
> However JSON lacks integers and only has doubles [0]; which would mean 53<br>
<br>
That's nonsense: JSON _has_ integers, but they are restricted (See: 6.  Numbers in RFC 7159)<br>
<br>
int = zero / ( digit1-9 *DIGIT )<br>
<br>
That was some stupid design decision IMHO.<br>
<br>
> bit integer precision is about the maximum we can reach.  It's unclear to<br>
<br>
The RFC mentions "IEEE 754-2008 binary64 (double precision) numbers"<br>
<br>
> me from the spec whether I should use doubles to encode these fields or use<br>
> strings.  Would it be possible to further clarify it?   If it is indeed a<br>
> number literal; this means the maximum date we can encode is<br>
> 9007199254740991 which corresponds to Tuesday, June 5, 2255   . This<br>
> honestly is too soon in the future for my comfort.  I suggest encoding 64<br>
> bit integers as string literals instead to avoid the truncation problem.<br>
> <br>
> [0] <a href="https://datatracker.ietf.org/doc/html/rfc7159#section-6" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc7159#section-6</a> <br>
<br>
<br>
<br>
<br>
</blockquote></div>