Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Fixing-JSON Conversation

tbray.org

Post reply on HN
Print view View original

11–20 of 55 posts

Re: The Fixing-JSON Conversation

#11

Post by realharo »

RoryH wrote: post #9

I think now is a good time to re-quote the man himself... Douglas Crockford.. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files…

The second part basically says "don't use JSON for config files, use some unspecified JSON superset".

Re: The Fixing-JSON Conversation

#12

Post by thaumasiotes »

thymelord wrote: post #3

Timestamps are so complicated once you factor in timezones and daylight savings that it doesn't belong in JSON. Time zones are not static. They can change from country to country, or even states within countries. Ditto for when daylight savings is enacted during the year - even changing over the years. There is no rhyme or reason to any of this. The data for this has to be stored in tables and time zone meanings can…

> (Speaking of leap seconds, who thought seconds going from 0 - 60 rather than 0 - 59 was a good idea?)

Who thought February going from 1-29 instead of 1-28 was a good idea?

I don't understand why everyone seems to believe that the phenomena are so inherently different.

Re: The Fixing-JSON Conversation

#13

Post by thaumasiotes »

niftich wrote: post #5
sanqui wrote: post #4

Personally, I would really like to see integer object keys (as opposed to only string keys). For simple numeric transformations, strings feel really heavy and require annoying conversion in languages. E.g. {"10": 60, "42": 2}.

The flipside is that an integer-keyed map is similar in meaning to an array, which associates by virtue of placement, an integer with the value sitting at that index. While it's possible to spec it to forbid this interpretation, Lua has made this interpretation a language feature, and it'd become impossible to construct an unambigous parser/printer in Lua for this new format.

> it'd become impossible to construct an unambigous parser/printer in Lua for this new format

How so? JSON is just text; you can parse it however you like. For example, I can write a parser that produces the byte sequence "It checks out." for any valid JSON input. A Lua JSON parser that represents objects with integer keys as maps with string keys, and a Lua JSON parser that represents objects with integer keys as sparse arrays, are both unambiguous and both correct (as to a hypothetical JSON which allowed integer keys). JSON is a format, not a Lua structure.

Even if your JSON data is

    { 10: 10, "10": "ten" }
there's no problem being able to write an unambiguous parser. Define what your parser does in that situation, and it's unambiguous.

Re: The Fixing-JSON Conversation

#14

Post by coldtea »

RoryH wrote: post #9

I think now is a good time to re-quote the man himself... Douglas Crockford.. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files…

>I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.

I call BS. If people want to have custom parsing directives they can send them out of band, encode them in the filename, or whatever. But they don't. And I've not seen this happening with most other serialisation formats either, so why would JSON be a particular target? After all it's value comes from being trivially parsable across languages, and that would be killed by custom parsing directives. Those wanting those would also implement their own parsers etc.

Addition: Besides, reading comments to decide how to parse, implies either "comments on top of the file" or a "2 stage parsing".

With 2 stage parsing, you could implement comments and whetever else yourself, even in pure JSON anyway.

As for "comments on top of the file", well, just disallow them (only allow comments after the first JSON object starts), and no issue with "parsing directives" anymore...

Re: The Fixing-JSON Conversation

#15

Post by coldtea »

realharo wrote: post #10
thymelord wrote: post #3

Timestamps are so complicated once you factor in timezones and daylight savings that it doesn't belong in JSON. Time zones are not static. They can change from country to country, or even states within countries. Ditto for when daylight savings is enacted during the year - even changing over the years. There is no rhyme or reason to any of this. The data for this has to be stored in tables and time zone meanings can…

Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. This talk explains it VERY nicely: https://www.youtube.com/watch?v=2rnIHsqABfM Basically just decide whether you're trying to store an absolute time (a timestamp will do) or a civil time (year, month, day, etc.) and treat them as two separate data types. (If you…

>Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value.

Not even close.

http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

Re: The Fixing-JSON Conversation

#16

Post by espadrine »

realharo wrote: post #10
thymelord wrote: post #3

Timestamps are so complicated once you factor in timezones and daylight savings that it doesn't belong in JSON. Time zones are not static. They can change from country to country, or even states within countries. Ditto for when daylight savings is enacted during the year - even changing over the years. There is no rhyme or reason to any of this. The data for this has to be stored in tables and time zone meanings can…

Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. This talk explains it VERY nicely: https://www.youtube.com/watch?v=2rnIHsqABfM Basically just decide whether you're trying to store an absolute time (a timestamp will do) or a civil time (year, month, day, etc.) and treat them as two separate data types. (If you…

If by timestamp you mean Unix time, you have to keep in mind that it evolves non-linearly. When a leap second happens, Unix time increases linearly by one second for that second, and jumps back one second, and again increases linearly by one second for the leap second.

If you have sub-second precision and expect Unix time seconds to always go forward, or if you expect every Unix second to last a second (eg. by computing Unix time differences), things might break.

https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

Re: The Fixing-JSON Conversation

#17

Post by realharo »

coldtea wrote: post #15
realharo wrote: post #10

Earlier quoted context omitted.

Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. This talk explains it VERY nicely: https://www.youtube.com/watch?v=2rnIHsqABfM Basically just decide whether you're trying to store an absolute time (a timestamp will do) or a civil time (year, month, day, etc.) and treat them as two separate data types. (If you…

> Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. Not even close. http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

If you watch the video I linked above, he explicitly mentions that 99% of the time you should not be dealing with any of those things manually - that if you find yourself working with offsets and DST values, it's a sign that you're most likely doing something wrong.

Re: The Fixing-JSON Conversation

#18

Post by efaref »

realharo wrote: post #11
RoryH wrote: post #9

I think now is a good time to re-quote the man himself... Douglas Crockford.. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files…

The second part basically says "don't use JSON for config files, use some unspecified JSON superset".

I find that YAML (a JSON superset) for config and JSON/CBOR on the wire works quite well.

Re: The Fixing-JSON Conversation

#19

Post by coldtea »

realharo wrote: post #17
coldtea wrote: post #15

Earlier quoted context omitted.

> Time is actually quite simple if you have a good mental model of what you're trying to represent and don't try to mix different concepts into a single value. Not even close. http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

If you watch the video I linked above, he explicitly mentions that 99% of the time you should not be dealing with any of those things manually - that if you find yourself working with offsets and DST values, it's a sign that you're most likely doing something wrong.

>that if you find yourself working with offsets and DST values, it's a sign that you're most likely doing something wrong.

The video is wrong then.

If you're writing an application that deals with times (e.g. stores and queries events with specific timestamps) and you don't take offsets and DST values into account, you get all kinds of weird edge cases.

Re: The Fixing-JSON Conversation

#20

Post by moonshinefe »

RoryH wrote: post #9

I think now is a good time to re-quote the man himself... Douglas Crockford.. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files…

Okay, so the reasoning is we remove a highly useful feature that most people who use JSON regularly want, because some people were abusing it and using terrible practices?

That's terrible reasoning.

Post reply on HN