- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Edit Admin
At least they're consistent in the use of on/off. Only value file_not_found is lacking.
Edit Admin
I'm confused, I thought the proper way to serialized timestamps is a ISO-8601 UTC timestamp (YYYY-MM-DDThh:mm:ss.sssZ). This is also the output you get from Date.toJSON(), so basically it's standardized at least for JavaScript.
Admin
Either that or just use UNIX time. What's easier than parsing an integer?
Edit Admin
I'd still say that standard is wrong. It's a terrible way to manage date information in a serialization format.
Admin
One former place I worked at had "yes"/"no" in config files (now this was XML, from before JSON was a thing). Except that your code needed to also support "Yes" and "YES" (etc.), which sometimes meant writing them all out, because the language had no concept of case-conversion or case-insensitivity (let's be real, it meant copy-and-pasting the relevant snippet).
I guess I had to take any yes for an answer.
Edit Admin
UNIX time kinda sucks due to it's messed up handling of leap seconds (not even going into the historic issues like the sloppy GMT transition). It's also not human readable, which defeats the point of a text based serialization format IMO while the ISO timestamp is both sortable, parsable and supports fractions.
Edit Admin
What would you exactly propose as a better alternative?
Admin
ISO timestamps are more human friendly if anyone is actually supposed to read the files manually. I won't contest that. But if you just want to pass data between programs over the internet (or some other means) with no human in the middle, as is the most common use case for JSON, it presents a clean and easy to parse and comprehend data format that is just confounding enough that people are more likely to google up and than find and use builtin parsing methods rather than rolling their own mess. Very much unlike date strings. And that, I feel is an advantage that should not be underestimated. That and not all languages have good parsing libraries builtin for anything but UNIX integers.
So I guess it's a matter of knowing your audience. Different tools for different purposes and all that.
Edit Admin
Typo: "parse the sting".
Edit Admin
Unix timestamps lack time zones.
That is generally worked around by assuming everyone is in the same time zone -- as in really not handling time zones at all. Hilarity ensues quickly as a system expands.
The other workaround is to first translate any time in a commonly shared timezone, eg UTC (or Mountain View time, for some specific vendor I shall not name :-)).
But again that only works within a closed system where everyone can comply. The point of JSON being Internet exchange with random recipients, a well formatted ISO time is the proper way to go.
I've seen schemas that just add both. Problem solved.
Edit Admin
I agree with the ISO approach. What I do /not/ agree with is Remy's preference for "exploding out as a sub-dictionary", by which I assume he means
Yes, it seems like the proper way to notate an object, but it is so much more complex when including HH:MM:SS and time zones that a single string is much more sane, especially since there are so many libraries which support it.
Edit Admin
As an aside, it is ridiculous to display the timestamp of each TDWTF comment without the time-of-day component. Can that be tweaked?
Edit Admin
Almost no one support even a fraction of the ISO 8601 format. RFC3339 was written to specify a subset (and a few exceptions) to ISO 8601 to make it more implementable, and this is what most people mean when they say "ISO 8601 formatted date". Still, a large fraction of code is still written that pretends all dates will have originated from some assumed time zone.
I worked on a bug where the JSON dataset had a field that represented end date and begin date for a report. The UI had a date picker, but didn't support time. It was assumed if you picked 1/1/2024 to 1/31/2024, that you wanted all of January. The back end read the value and dropped the time portion.
Well, when central zone zone users picked "1/31/2024", this was serialized as "2024-01-31T00:00:00-06:00". When our eastern time zone server deserialized it, we got "2024-02-01T00:01:00-05:00". Then we dropped the time portion, and got the wrong day.
Dates are hard and simply having a "universal serialization format" handles like 1% of the real world problems. We found the best solution was to change the JSON to have three number fields with the year, month, and day portions. It increased clarity, and was really hard to screw up.
Edit Admin
Spot on. I deal with "assumed time-of-day results in off-by-one date" constantly in one of my two major applications, but good luck trying to get my customer to understand the intricacies.
Edit Admin
Why?
The programming language I use at work to interface with the database we use, it has a GetDate() and GetDateTime() function that you can call on the JSON object, which will perfectly consume the JSON date and datetime format using the correct ISO standard.
I see nothing wrong here with how JSON does the dates.
Numbers on the other hand, annoying that one has to wrap the thing in a Number() to tell JSON that it is a number, but that's more on Javascript itself.
When I submit my data to my API, the JSON object correctly has datatypes for integer, decimal (both as Number), date, datetime, boolean, and string.
Edit Admin
Why?
The programming language I use at work to interface with the database we use, it has a GetDate() and GetDateTime() function that you can call on the JSON object, which will perfectly consume the JSON date and datetime format using the correct ISO standard.
I see nothing wrong here with how JSON does the dates.
Numbers on the other hand, annoying that one has to wrap the thing in a Number() to tell JSON that it is a number, but that's more on Javascript itself.
When I submit my data to my API, the JSON object correctly has datatypes for integer, decimal (both as Number), date, datetime, boolean, and string.
Edit Admin
Oh that's hillarious, the submit button doesn't disable when you click it, so you have the chance of double-posting :P