- 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
Admin
At least they're consistent in the use of on/off. Only value file_not_found is lacking.
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?
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.
Admin
well, at least it forces, in a twisted way, something called type-safety. I guess... Just a boolean that can have two states: "on" and "off". the underlying abstraction of it to stringly typed values are no more than syntactic sugar.
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.
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.
Admin
Typo: "parse the sting".
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.
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.
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?
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.
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.
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.
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.
Admin
Oh that's hillarious, the submit button doesn't disable when you click it, so you have the chance of double-posting :P
Admin
Why people still use Unix time when the pending cutoff date draws nearer and nearer? Real systems use the proper timestamp, the Julian one, milliseconds since 1.1. 4713 BC, 12:00.
Admin
Yeah, sounds about right. I have to periodically stomp on developers using "Y" and "N" in the APIs, because that's how booleans are typically represented in the database. Bonus points for those who define an enumerated type for it... you know what we call an enumerated type with Y/N values in it? A boolean, dumbass!
Admin
@dpm ref
It's doubly dumb here at WTF versus other possible message boards / comment systems , because with the exception of weekends or especially popular WTFs, substantially 100% of posts are made only to the current WTF on the date it is current. Most of the few posts, like mine here, that are from the second day are dated that way just due to timezone issues around the world.
Admin
Why should it be limited to "yes" and "no"? Let's also accept "si", "no", "oui", "non", "ja", "nein", etc.
Admin
It's just such a weird mindset to be all "I hate the way X technology arose in the context of history. Why couldn't it arise in the abstract realm of imagination?"
Admin
Please remember that boolean types need to support, next to Y and N, the required value FNF (FILE_NOT_FOUND), in order to be enterprise-ready and certified for corporate use.
Admin
I would say eventually someone will want to read the file themselves, for example to try to see why something is not working right. The chance of this of course goes up if you design it with the assumption nobody will ever read the file.
Admin
This is a configuration file / command script for a managed switch. The reason the json requires these values is because that's what the CLI commands require. Managed switches use "on" and "off" (thinking Cisco, HP, ..), and the command names correspond to that.
The back-end thing probably takes whatever input you give it and passes it to the config file parser. It might ever write the JSON to a flat file and pass it to the config-read function.
Admin
I've seen a lot of embedded systems (read: routers) that output "JSON"/interpolated JavaScript this way. I can only assume it's because they're still using some stringly typed configuration file and library fed into a HTML template, then over time needed to be turned into a JSON API. But rather than use a proper JSON library to serialise it, it gets fed into a JSON template instead with every value as a string, thus putting the onus of parsing onto the client. A good tell is that you'll never see
null, just a blank string.Admin
I am not saying that you are wrong. It's just that in my experience JSON does not really seem to be used for files anyone is supposed to read. It's more of a machine to machine protocol for serializing objects and such and sending stuff over the wire in general. So you won't have much opportunity to read them ever unless it's in an error log. And at that point the exact date being sent is usually inconsequential as long as the format is not obviously broken.
But I am a sample of one here, so my experience, whilst wast, is obviously biased to the sort of systems I worked with.
Admin
Come on, it ain't YAML
Admin
Us Pythonistas just delegate the whole mess to Pydantic, and stop worrying. Except there's not a default date serialiser......