Mike Jones <[email protected]> writes:
> Thanks for pointing this out, Tom. I agree that we should use the POSIX
> semantics. Other experts on the list - is there an RFC containing the
> appropriate definition, or should I just reference my old POSIX.1 spec (IEEE
> Std 1003.1-1988)?
Hi Mike,
My reference for Seconds Since the Epoch in IEEE 1003.1-2013 is
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
I believe there have been several technical and editorial corrections to
that section of POSIX since 1988, so a more recent citation might be
appropriate.
As far as I know, there is no RFC containing a specification of the
POSIX Seconds Since the Epoch definition. I think there is also no RFC
that gives general guidance on the handling of leap seconds when
protocol time stamps are represented as a number of seconds elapsed
since some epoch.
http://www.eecis.udel.edu/~mills/leap.html (and to some extent, RFC
5905) provides a description of what happens with leap seconds in NTP.
RFC 7164 provides a useful and generally applicable contrast among
behaviors of official UTC, typical POSIX implementations, and NTP (even
though the nominal subject of the RFC is the interaction of leap seconds
with RTP).
> As for whether IntDate must be an integer, the normative text says "no".
> It's defined as "a JSON numeric value", which allows the values to be
> non-integers. The name "IntDate" is misleading in that way. I'll try to
> come up with a better name for use in the next version of the spec.
Thanks. RFC 7164 shows how there is additional ambiguity of time stamps
at the sub-second level. I suspect that this does not have significant
consequences for most use cases of JWT. You might or might not want to
mention that there will be some ambiguities or anomalies in time stamps
near leap seconds, but that they will not have serious consequences for
most applications.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
