Just use Unix time everywhere.
ISO8601 won't scale to universe-level applications!
:)
International Atomic Time (TAI), which differs by UTC by 37 seconds since it doesn't count leap seconds, solves everything I know of. Although the clocks aren't in a single reference frame, the procedure for measuring their differences and averaging them to define TAI is well defined and so sets an objective standard for "what time is it on Earth".
JSON isn't meant to be self-describing format. There is JSON schema or the like if that is what you are after.
And yet to a very large extent, it is. Strings, numbers, booleans, arrays, and associative maps made the cut. Timestamps would be a pretty reasonable addition. It would certainly cut out all the controversy here.
Yes :)
That's the beauty of it: time is just a number (of seconds since 1 January 1970).
> Which scalar data type should your parser use?
Integer, since it's an integer number of seconds.
> And is it seconds since epoch or milliseconds since epoch?
Unix time is always seconds.
> That's the beauty of it: time is just a number (of seconds since 1 January 1970).
Having a bare number where the units and zero point rely on out-of-band information is not self-describing.
If you want something self-describing, maybe look into XML?
Wasn't there a BSD that used double instead of long for time_t for a while ages ago?
Javascript time (that 'JS' in JSON) is always milliseconds.
Then it is a complete non-starter for "just use ______". I work on software that requires millisecond precision (honestly it would benefit from even greater precision) at the transport layer. It's not even really doing anything spectacularly complex or unusual. Seconds simply aren't sufficient for tons and tons of use cases.
> Yes :)
> That's the beauty of it: time is just a number (of seconds since 1 January 1970).
> > Which scalar data type should your parser use?
> Integer, since it's an integer number of seconds.
> > And is it seconds since epoch or milliseconds since epoch?
> Unix time is always seconds.
Whilst time can indeed be modelled as "just a number", Unix time spectacularly fails to achieve even that.
* It can go backwards * Simple subtractions do not give accurate intervals
It's not a good measure of time. Don't use it as such.