Re: Question about timestamps in the USER_RECORD spec

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 26.10.21 10:41, Arian van Putten (arian.vanputten@xxxxxxxxx) wrote:

> 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
> bit integer precision is about the maximum we can reach.

The spec itself doesn't really mandate this is implemented in
double, the spec just says "sticking to doubles would be nice".

Actual implementations implement this differently IRL. Python based
implementations have arbitrary precision for this. sd-bus uses
uint64_t, or int64_t or long double. It prefers the integer types if
the value fits, and uses the floating point type otherwise. json-glibc
uses int64_t or double.

There are plenty of specs that rely that 64bit integers work with full
range (OCI for example, for much of its resource management stuff).

> It's unclear to 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.

You appear to plan for quite a long life ;-)

Frankly, this is not a problem specific to user records. A multitude
of JSON formats tend to store dates this way. The overflow is still
200y out. I think that leaves plenty time to teach implementations
full 64bit support, and I am pretty sure that the ones that will deal
with user records will catch up sooner or later.

> I suggest encoding 64
> bit integers as string literals instead to avoid the truncation
> problem.

I am sorry, but I am not convinced this is a pressing issue. I value
cleanliness and obviousness a lot more than theoretic issues that
might happen 200 years from now. In particular as they are issues that
can be dealt with in offending JSON implementations, and limitations
in the parser implementations shouldn't really leak in to the spec I think.

I mean, at this point it isn't even clear humanity will survive that
long, and I seriously doubt that systemd is the one project that
survives humanity.

What might make sense is to add a comment about the whole situation to
the spec and be done with it:

     "Please not that this specification assumes that JSON numbers may
     cover the full integer range of -2^63 … 2^64-1 without loss of
     accuracy (i.e. INT64_MIN … UINT64_MAX). Please read, write and
     process user records following this specification only with JSON
     implementations that guarantee this range."

Lennart

--
Lennart Poettering, Berlin