This is the killer for me. Most people promote ISO 8601 as a “definitive” date structure, when it actually supports a lot of different formats. What they actually want is usually RFC 3339.
A single separator is better than a choice of separators to mean the same thing.
A space is not as apparent in a large log of data as a capital T
Human language is not as strict as a programming language. There is a reason you see people still using “alot” and “a lot”. That just proves it’s easy to overlook and commonly happens.
The difference:
2023-12-12T21:18Z is ISO 8601 format
2023-12-12 21:18 is RFC 3339 Format
A small change
ISO 8601 also allows for some weird shit. Like
2023-W01-1which actually means2022-12-31. There’s a lot of cruft in that standard.This is the killer for me. Most people promote ISO 8601 as a “definitive” date structure, when it actually supports a lot of different formats. What they actually want is usually RFC 3339.
Doesn’t the ISO also includes time periods? Because if it does, those are amazing.
Without any explanation, you should be able to decypher these periods just by looking at them:
Hmm I don’t get the T there tbh
It makes the difference between M meaning month or M meaning minute. Small differences.
So it’s redundant in P1DT4H? Or is it a mandatory separator between ymd and hms?
It’s mandatory, which also makes it nice and predictable.
Week numbers are convenient for projects in which key delivery dates are often expressed in his many weeks out they are.
wtf what is that gross
I definitely don’t agree that the RFC is easier to read, the two numbers can appear to be one at a quick glance without a separator.
But there is a separator between the numbers: the same one that also very reliably separates the words in this comment
Both are valid (if you’d add seconds) in both RFC 3339 and ISO 8601, but timezone support is the same here and there…