The I-JSON Message Format • Hacker News Board

Re: The I-JSON Message Format

#41

Post by nknighthb » Tue, Mar 24, 2015, 1:43 AM UTC

npinguy wrote: post #23

msie wrote: post #17

To me, I know of Tim Bray because of XML.

He also authored one of the two competing standards for JSON: http://tools.ietf.org/html/rfc7159

They're really not competing at this point. 7159 is the one spec to rule them all. ECMA-404 (which was kind of silly to start with[0]) isn't really relevant to most developers anymore.

ECMA-262 even explicitly uses 7159's predecessor (4627) with two exceptions[1], one of which is the top-level compatibility headache 7159 fixed, and the other just requires the API to disregard the "MAY" in section 4.

[0] https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-J...

[1] http://www.ecma-international.org/ecma-262/5.1/#sec-15.12

Re: The I-JSON Message Format

#42

Post by deitcher » Tue, Mar 24, 2015, 6:23 AM UTC

pdw wrote: post #36

pimlottc wrote: post #27

Earlier quoted context omitted.

Epochs don't tell you what time zone you're working with and they aren't very easy to read/debug at a glance.

Another annoyance is seconds since epoch (traditional Unix) vs milliseconds since epoch (e.g. Java).

And JavaScript is milliseconds as well. I think either would be fine, as long as it is an agreed standard. Personally, I use ms, because most programming langs can instantly convert with any additional math. But it probably is wasteful. Then again, 1000 is just a few bits on each...

Re: The I-JSON Message Format

#43

Post by deitcher » Tue, Mar 24, 2015, 6:24 AM UTC

jameshart wrote: post #37

deitcher wrote: post #29

Earlier quoted context omitted.

Fair enough @pimlottc. But most of the time I am far more concerned with accurately capturing a moment in time than I am with making it instantly readable. I also have helped some companies that ran into serious datetime management issues when they worked with strings that led engineers to assume a certain timezone, others to assume others, and chaos ensued. Epochs may not be instantly readable, but they do force eve…

So by epoch, obviously you mean the number of seconds since Jan 1 1970. Midnight - 00:00, right? Ah... but then... UTC? or TAI? There's a 35 second difference, after all. There's a school of thought that the UNIX epoch counts from 1970-01-01 00:00:10 TAI...

I had not thought of that. Ha!

I would go for UTC, since that is what 99.99% of the people think of (and so few even know about TAI, except for the smart ones like @jameshart! :-) )

Re: The I-JSON Message Format

#44

Post by deitcher » Tue, Mar 24, 2015, 6:26 AM UTC

smoyer wrote: post #39

deitcher wrote: post #19

Earlier quoted context omitted.

I love it. When I first started in IT (1994, don't ask...) working with London and Tokyo and San Fran and Singapore and everyone wrote dates differently. I just started writing YYYY-MM-DD everywhere, and all of the questions went away.

Looks like ISO-8601 to me! We've standardized on using this format (extended to include time where necessary) whenever our JSON objects include a date or date/time. We've also standardized on UTC. Since our system clocks are already synchronized that way, it's easy for us and we simply i18n/l12n them on entry and/or display.

It was, I just didn't know it at the time! I was simply looking for some way to write emails and spec docs in a way that everyone would have a common frame of reference with zero extra work.

Yeah, in storage (as above), I use epoch all the way through and convert as needed. But as the thread above shows, not everyone likes this path...

Re: The I-JSON Message Format

#45

Post by jameshart » Tue, Mar 24, 2015, 2:13 PM UTC

nknighthb wrote: post #40

jameshart wrote: post #37

Earlier quoted context omitted.

So by epoch, obviously you mean the number of seconds since Jan 1 1970. Midnight - 00:00, right? Ah... but then... UTC? or TAI? There's a 35 second difference, after all. There's a school of thought that the UNIX epoch counts from 1970-01-01 00:00:10 TAI...

POSIX specifies the Epoch to be UTC and has since at least 2001. People may have other opinions on how it should be specified, but if you're going to follow POSIX as it exists, you're not left with a choice in the matter. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...

But POSIX also claims there are 86400 seconds in a day, which is not always true for UTC. There are two ways of dealing with that - POSIX says that the correct way is to just count seconds, but reset every UTC midnight to (number of days since 1970-1-1) * 86400, which means that when leap seconds occur some epoch numbers are ambiguous (or in a leap-second-deletion, are skipped). NTP ignores POSIX and says that the way to deal with this is to vary the length of a second during a day which contains a leap second.

And we're talking about JSON here, so isn't the ECMA-262 standard for dates more relevant than the POSIX standard? ECMAScript has some very fuzzy ideas about dates.

Re: The I-JSON Message Format

#46

Post by nknighthb » Tue, Mar 24, 2015, 2:55 PM UTC

jameshart wrote: post #45

nknighthb wrote: post #40

Earlier quoted context omitted.

POSIX specifies the Epoch to be UTC and has since at least 2001. People may have other opinions on how it should be specified, but if you're going to follow POSIX as it exists, you're not left with a choice in the matter. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...

But POSIX also claims there are 86400 seconds in a day, which is not always true for UTC. There are two ways of dealing with that - POSIX says that the correct way is to just count seconds, but reset every UTC midnight to (number of days since 1970-1-1) * 86400, which means that when leap seconds occur some epoch numbers are ambiguous (or in a leap-second-deletion, are skipped). NTP ignores POSIX and says that the wa…

POSIX specifies that there are 86400 seconds in a day. POSIX is not making claims about reality, it is specifying its own reality. That's what standards do.

ECMA-262 isn't really relevant at all, since it's not the (or even an) authority on JSON. JSON was simply derived from it -- in an incompatible way at that. It's doubly irrelevant since you were talking about Unix, so that's what I was addressing.

By the way, your phrasing is odd/confusing. You're talking about "epochs" in a strange way. In Unix/POSIX land, there is one epoch, "The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC).". Unix timestamps are derived from the epoch, they do not define it.