The I-JSON Message Format(tbray.org) |
The I-JSON Message Format(tbray.org) |
Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization.
Unfortunately from what I can tell, I-JSON doesn't appear to solve this problem (or does it??) One nice thing about BSON is they made Date types first class citizens of the format.
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.
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.
Faster, smaller, pretty sure it will parse on the other end.
4.3. Time and Date Handling
Protocols often contain data items that are designed to contain
timestamps or time durations. It is RECOMMENDED that all such data
items be expressed as string values in ISO 8601 format, as specified
in [RFC3339], with the additional restrictions that uppercase rather
than lowercase letters be used, that the timezone be included not
defaulted, and that optional trailing seconds be included even when
their value is "00". It is also RECOMMENDED that all data items
containing time durations conform to the "duration" production in
Appendix A of RFC 3339, with the same additional restrictions.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 incentive I can give this community to try to standardize their organizations around this standard!
but the plaintext version does:
http://www.rfc-editor.org/rfc/rfc7493.txt
Maybe the document is still in flux and the text version represents a later addition?
EDIT: Oops, my first link is to the original JSON spec. Sorry for the confusion!
An I-JSON implementation supporting a "Must-Ignore" policy SHOULD pass any such new protocol elements on, untouched, to any downstream consumers of the message, because those downstream consumers may understand the new elements.
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.
[edit] Actually, it looks like the guts of this tool live here: https://github.com/zaach/jsonlint
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.
In JavaScript Object Notation, everything's a float. There are no integers, just floats that happen to not have any fractional elements.
Numbers are the weakest part of the JSON spec in general because Javascript has very weak numbers. A spec merely intending to tidy up certain questionable corners hasn't really got license to "fix" the numbers problem.
(And just to make it clear one more time, I fully agree that the numbers are really problematic in JSON... I just don't think that problem can be fixed here. It would take a JSON 2.)
It has been said that the limit of the ratio of (creating, groking, interacting with) the hundreds to thousands of XML schemas/documents that invariably creep up in the average large-scale-XML-using enterprise environment versus (doing actual work) increases without bound as t goes to infinity.
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
object --> array --> object --> array
I must have spent a few hours trying to figure out why Angular wasn't iterating through the first array, only to discover that it was being parsed like so:
object --> object --> object --> object
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.
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...
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.
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...
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! :-) )
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.
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.