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

21–30 of 55 posts

Re: The Fixing-JSON Conversation

#21

Post by realharo »

coldtea wrote: post #19
realharo wrote: post #17

Earlier quoted context omitted.

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.

No, the point is that you should not be doing those thing manually, i.e. you should never be adding integer offsets to something or doing similar operations. Instead, all the rules for conversions between times are already stored in the timezone database, so all you should do is something like

    ToAbsolute(CivilTime, TimeZone)
and the reverse. He also mentions (at 26:50) proper ways of dealing with repeating and non-existent civil times close to DST transitions (and sane default ways if you just don't want to bother).

When talking about JSON or serialization formats specifically, none of the complexities need to ever leak into the representation.

Re: The Fixing-JSON Conversation

#22

Post by espadrine »

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…

> The only reliable time stamp is UTC without leap seconds.

That doesn't make a lot of sense, as UTC does have leap seconds. It is similar to saying that the fastest car has no wheels, when you really mean that the fastest vehicle is a rocket.

TAI is the most reliable and easiest to work with. It relies on atomic clock seconds at sea level. https://en.wikipedia.org/wiki/International_Atomic_Time

However, it already has a difference of roughly 40 seconds with UTC (and therefore civil time), and dropping leap seconds in civil time will shift midnight to later in the day.

But as the frequency of leap seconds rapidly increases, maintaining UTC will become harder. They will consider dropping leap seconds from UTC in 2023. It is unlikely that people care about having the sun rise at midnight in 30000 years.

Re: The Fixing-JSON Conversation

#23

Post by beagle3 »

coldtea wrote: post #14
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 targe…

When I read this statement, I was thinking of Pascal style comment directives, e.g.

    { 
      field1: 'hello', 
      //#if (protocol_version>3)
      field2: 'hello',
      //#endif

      /* #charset utf-8 */ field3: 'world world' /* #charset default */
    }
Which falls into neither "comments on top" nor "2 stage parsing". Unlike the C preprocessor, which "eats" whole lines starting with #, Pascal used a {$directive arguments} inline comment style.

Re: The Fixing-JSON Conversation

#24

Post by lmm »

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".

https://github.com/typesafehub/config/blob/master/HOCON.md makes it specified.

Re: The Fixing-JSON Conversation

#25

Post by lmm »

moonshinefe wrote: post #20
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.

http://www.haskellforall.com/2016/04/worst-practices-should-... . And it seems to have worked out well for JSON.

Re: The Fixing-JSON Conversation

#26

Post by mort96 »

coldtea wrote: post #14
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 targe…

If people really wanted parsing directives, they could just say that keys starting with # and their values are parsing directives - e.g:

    {
        "#if": "parserversion > 1.5",
        "key": "somevalue",
        "#else": "",
        "key": "othervalue"
    }
Thought I also don't really see any reason to include parsing directivesin JSON.

Re: The Fixing-JSON Conversation

#27

Post by _pmf_ »

Zardoz84 wrote: post #7

SDLang !!!! : https://sdlang.org/ Full example : https://github.com/Abscissa/SDLang-D/wiki/Language-Guide#exa... Examples: Creating a Tree plants { trees { deciduous { elm oak } } } Creating a Matrix myMatrix { 4 2 5 2 8 2 4 2 1 } A Tree of Nodes with Values and Attributes folder "myFiles" color="yellow" protection=on { folder "my images" { file "myHouse.jpg" color=true date=2005/11/05 file "myCar.jpg" color=false da…

That's beautiful!

Re: The Fixing-JSON Conversation

#28

Post by willvarfar »

If // and /* are used as comments, then most of this new extended-JSON will still be valid Javascript.

If # is used as comments, then this breaks documents being Javascript.

The post says that "don't eval() JSON ever", but that's like Crockford leaving out comments originally in order to stop them being abused as processor directives...

Re: The Fixing-JSON Conversation

#29

Post by tfm »

mort96 wrote: post #26
coldtea wrote: post #14

Earlier quoted context omitted.

> 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 targe…

If people really wanted parsing directives, they could just say that keys starting with # and their values are parsing directives - e.g: { "#if": "parserversion > 1.5", "key": "somevalue", "#else": "", "key": "othervalue" } Thought I also don't really see any reason to include parsing directivesin JSON.

Alas, there's no guarantee that the order of key/value pairs within an object will be preserved (not even within JS anymore!). But that's okay, we can always reformat the ordered data as an array or write a custom parser ... oh.

I don't see any reason to include parsing directives in JSON either, but it's a wild world out there and people do all sorts of strange things. Seems that a few of those folks were working at Yahoo and made the mistake of letting Doug see their code when JSON was in prototype phase, so no JSON comments for anyone. Whoops!

Re: The Fixing-JSON Conversation

#30

Post by DonHopkins »

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…

Ugh. Comments are also useful for disabling things without actually deleting them.

My hackey in-band work-around is for the persistence layer (and other code) to ignore any dictionaries in an array that have the "//" key, so I can put a "//": "DISABLED" key at the top of a dict to disable it (and document that and why it's disabled).

Post reply on HN