[systemd-devel] [EXT] Question about timestamps in the USER_RECORD spec

[Arian van Putten]

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 at rz.uni-regensburg.de> wrote:

> >>> Arian van Putten <arian.vanputten at gmail.com> schrieb am 26.10.2021 um
> 10:41 in
> Nachricht
> <CAE0h1269nSwDOGJc9BKMRRc2dtVJXZVHNZkzCpCQFVddfYGvXQ at mail.gmail.com>:
> > 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211028/7687ec21/attachment-0001.htm>