3 ms·

Presumably you mean unix time as a numeric scalar in the JSON. That is still not self-describing - is it time, or just a number? Which scalar data type should y

Presumably you mean unix time as a numeric scalar in the JSON. That is still not self-describing - is it time, or just a number? Which scalar data type should your parser use? And is it seconds since epoch or milliseconds since epoch?

cortesoft 7y ago
It should be maintained as a numeric scalar until you are going to do something with the value... and if you are going to do something with the value, you should know if it is a date or not. JSON isn't meant to be self-describing format. There is JSON schema or the like if that is what you are after.
- stickfigure 7y ago
  JSON isn't meant to be self-describing format. 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.
yellowapple 7y ago
> is it time, or just a number? 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.
- dragonwriter 7y ago
  > > That is still not self-describing - is it time, or just a number? > 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.
  - yellowapple 7y ago
    JSON has never been self-describing. Literally every use of JSON is fundamentally dependent upon some degree of out-of-band information. If you want something self-describing, maybe look into XML?
- nitrogen 7y ago
  Unix time is always seconds. Wasn't there a BSD that used double instead of long for time_t for a while ages ago?
- stickfigure 7y ago
  > Unix time is always seconds. Javascript time (that 'JS' in JSON) is always milliseconds.
- eyelidlessness 7y ago
  > Unix time is always seconds. 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.
- growse 7y ago
  > > is it time, or just a number? > 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.

cortesoft 7y ago

It should be maintained as a numeric scalar until you are going to do something with the value... and if you are going to do something with the value, you should know if it is a date or not. JSON isn't meant to be self-describing format. There is JSON schema or the like if that is what you are after.

stickfigure 7y ago
JSON isn't meant to be self-describing format. 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.

yellowapple 7y ago

> is it time, or just a number? 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.

dragonwriter 7y ago
> > That is still not self-describing - is it time, or just a number? > 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.
- yellowapple 7y ago
  JSON has never been self-describing. Literally every use of JSON is fundamentally dependent upon some degree of out-of-band information. If you want something self-describing, maybe look into XML?
nitrogen 7y ago
Unix time is always seconds. Wasn't there a BSD that used double instead of long for time_t for a while ages ago?
stickfigure 7y ago
> Unix time is always seconds. Javascript time (that 'JS' in JSON) is always milliseconds.
eyelidlessness 7y ago
> Unix time is always seconds. 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.
growse 7y ago
> > is it time, or just a number? > 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.