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

The I-JSON Message Format

tbray.org

Post reply on HN
Print view View original

21–30 of 46 posts

Re: The I-JSON Message Format

#21

Post by tomchristie »

thom_nic wrote: post #4

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it. Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization. Unfortunately from what I can…

> I-JSON doesn't appear to solve this problem

It's not within the scope of what I-JSON is intended to address. This is a more formally specified and slightly more constrained variation of the existing JSON spec. Adding new datatypes would mean that it would no longer be JSON.

Re: The I-JSON Message Format

#22

Post by MichaelGG »

snuxoll wrote: post #13
btown wrote: post #10

Earlier quoted context omitted.

For what it's worth, Salesforce even conforms to ISO 8601 internally. So, you know, if you're trying to develop agile tools for translating between JSON and Salesforce API records, then, um, things should just work... takes a brief moment to contemplate the reality of his existence The flip side of this is that if you're not using ISO 8601 in your JSON, you're doing worse than Salesforce. That's about as good of an i…

I'm really surprised there's still a lot of people out there that don't use ISO 8601, I haven't used anything but for nearly a decade :/

Twilio was the most shocking example. They use that braindead[1] "RFC" style that includes day of week and month name in English. I remember feeling it looked like the most ugly part of their API; no reason for this silliness. (Maybe they've changed it since I looked a few years ago).

1: It made sense in like the early 70s when people read and wrote all headers by hand. It's been stupid for a much longer time than it made sense though.

Re: The I-JSON Message Format

#25

Post by thom_nic »

tomchristie wrote: post #21
thom_nic wrote: post #4

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it. Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization. Unfortunately from what I can…

> I-JSON doesn't appear to solve this problem It's not within the scope of what I-JSON is intended to address. This is a more formally specified and slightly more constrained variation of the existing JSON spec. Adding new datatypes would mean that it would no longer be JSON.

I'll agree there aren't many ways this could be solved without breaking compatibility with JSON. Certainly something like {"created": Date("2013-12-1T12:00:00Z")} a la BSON seems elegant but is incompatible with JSON.

Maybe something like "String values that match (some computationally inexpensive ISO-8601-matching regex) shall be converted to Date instances by the JSON parser" could be possible without huge compatibility issues.

I guess I was mostly using this topic to voice what I'd imagine is a common point of frustration in an otherwise great data interchange format.

Re: The I-JSON Message Format

#26

Post by dochtman »

brianolson wrote: post #24

See also RFC 7049 "Concise Binary Object Representation" (CBOR), a 'binary JSON' http://tools.ietf.org/html/rfc7049 http://cbor.io/ Faster, smaller, pretty sure it will parse on the other end.

The fun part is that this RFC was edited by Carsten Bohrmann.

Re: The I-JSON Message Format

#27

Post by pimlottc »

deitcher wrote: post #20
thom_nic wrote: post #4

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it. Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization. Unfortunately from what I can…

Dunno, I always liked storing date/time as epoch. Every language under the sun seems to have a native method for working with it. Yeah, I need to deal with de/serialization, but it is a small price to pay, no?

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

Re: The I-JSON Message Format

#28

Post by nly »

Kind of a bummer that nothing was suggested wrt tightening the number grammar. "99" and "99e0" are both valid serializations of 99, and "0e7" and "0" of zero. JSON also allows arbitrary trailing and leading 0s in the fraction and exponent, respectively. Personally I don't know why for instance "0.0" can't be the only valid interpretation of a double 0 and "0" be the only valid interpretation of an integer 0. In fact, why can't all floats that are ambiguous wrt an integer interpretation have a ".0" tail?

Also, if you're going to stash binary data in to quoted JSON strings then why base64url encoding and not Z85[0]? It's more efficient and easier to decode.

Using schema-less formats generally sucks.

[0] http://rfc.zeromq.org/spec:32

Re: The I-JSON Message Format

#29

Post by deitcher »

pimlottc wrote: post #27
deitcher wrote: post #20

Earlier quoted context omitted.

Dunno, I always liked storing date/time as epoch. Every language under the sun seems to have a native method for working with it. Yeah, I need to deal with de/serialization, but it is a small price to pay, no?

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

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 everyone onto the same page.

In any case, I tend to view a timezone as a separate piece of data than the actual moment in time (but I know others have a different paradigm): datetime = accurate moment in time; timezone = the timezone for which this should be viewed, or was captured or, etc.

Re: The I-JSON Message Format

#30

Post by unwind »

zdw wrote: post #6
atonse wrote: post #2

For a lot of the tips (don't repeat keys, use ISO8601 dates), most JSON libraries should follow these conventions. So as long as you aren't hand-generating your JSON, you'd need to do very little work to conform to these guidelines.

More specifically, RFC3339 dates, which are ISO8601 with a lot of extraneous cruft (week of year? really?) removed.

Week numbers are a very common way of talking about time in some locales.

For instance in my native Sweden, it's very common when e.g. scheduling things at work to talk about which week something will happen.

Sites like http://vecka.nu make it easy to check the current week number (the domain name translates as "week.now") whenever you have internet access, paper calendars include it, and so on. It's really very common.

Post reply on HN