Hacker News Reader

Comment by mmastrac | Hacker News Reader

I love this concept; my only concern is that by adding comments, it becomes difficult to round-trip a JSON document. XML has the concept of comment nodes that can survive a round-trip, but there's no easy way to do this in JSON. Perhaps you could limit where comments could go (ie: tagging object properties or array items only) and add a "__comments__" property to an object and/or list that contains the matching comments for the items in the object and/or array.

Also, please add ISO-8601 dates (repeating my comment below)!

{ timestamp: new Date("2007-04-05T14:30Z") }

View on HN

For the love of god yes! a standardised date format is the only thing that really needs changing in json.

We already have a standardised date format, as such. A specific subset of ISO 8601:

  > JSON.stringify(new Date())
  "2014-03-02T15:08:55.309Z"

What's the benefit of cluttering JSON with a constructor like new Date(...) when you can just standardize on ISO-8601 strings? JSON is not supposed to be eval'ed anymore.

JSON is JS. If I manually create a JSON document, it should also be valid in the context of code. And strings are not dates -- they are strings. That's why we have boolean and number literals.

So many other languages use JSON as a data format that keeping a weird constructor call in there would do more harm than good. Especially since you can keep the formatting code in your codebase and invoke that when you need to use that property.

We had a bug once when some logger output happened to get passed through JSON. The receiving code expected arrays of strings, but at some point one of the records happened to just contain a date. That ended up getting deserialised as a real Date object, not a string, which obviously broke. Using the same representation for different data types just seems to be asking for bugs.

The problem is that your code should have been expecting that field to be a string and nothing else, and other fields that contain dates to be a date and nothing else. In other words, if you're parsing JSON in this manner you need to apply some sort of schema to the data or have another field in the record denote the datatype. Anytime you're trying to auto-magically detect the datatype of the field, you're gonna have a bad time.

What is wrong with standard unix timestamps?

Numbers, booleans, and null should be removed. What's wrong with using strings for every value?

There's not a bijection between UTC time and "standard unix timestamps" due to leap seconds

if you encode TAI in a unix timestamp, this would be a solved problem, but due to the fact that you cannot encode the time zone in the "unix timestamp datatype", you'd also have to handle cases in which people chose another timezone.

This makes it good enough for storing data (it'd be nice if the size of the data type would be explicit) but suboptimal for interoperability with other systems that could be using a different standard

either you encode the timezone in a different field in your JSON, or someone (the JSON5 people?) could define a literal for timestamps like:

t+1393752828Z (this would also eliminate the ambiguity between timestamps and number literals)

Yes please. I thought this would be listed first when I clicked on the link.

Reply on news.ycombinator.com