Note that Python still lacks any way to parse these dates in the standard library. You have to use a third party library to parse them. You might think `datetime.fromisoformat` parsed ISO dates but you'd be wrong; it doesn't support the trailing Z or any other form of timezone information. The docs are clear about this, and the developer discussion I've read basically boils down to "it's too hard to parse ISO dates so we didn't do it here." This discussion has been going on for years.<p><a href="https://stackoverflow.com/questions/127803/how-do-i-parse-an-iso-8601-formatted-date" rel="nofollow">https://stackoverflow.com/questions/127803/how-do-i-parse-an...</a>
This is very neat, but maybe not completely accurate. "2021-10-24 11:02:03Z" is outside iso8601 in the figure, but I think it's valid iso8601. True, "T" is the One True date-time separator in iso8601 (IMO its biggest wart, as it looks awful for human eyes: "2021-10-24T11:02:03Z"). But according to the draft standard[1], page 21:<p>> By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard<p>[1] The actual ISO standard is not freely available, but the Library of Congress has free draft standards:
<a href="https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf" rel="nofollow">https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...</a>
<a href="https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_iso_wd_8601-2_2016-02-16.pdf" rel="nofollow">https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i...</a>
…and none of these do timezones properly! If your birthday party is:<p><i>2022-05-01T16:00+1000</i><p>…but tomorrow’s government abolishes daylight savings time, your birthday event has to change to:<p><i>2022-05-01T16:00+0900</i>.<p>If you’d just said:<p><i>2022-05-01T16:00 Asia/Eastern_Siberia</i><p>…you’d be fine and everyone will show up at the right time.
Because the digits are of varying widths in the standard Apple system font, the ticking seconds cause the date strings to jiggle back and forth and the table column widths to jiggle as well!<p>However, you can use CSS to select the fixed-width variant for digits. This is a perfect example of a use case for:<p><pre><code> * {
font-variant-numeric: tabular-nums;
}</code></pre>
I never really thought about six-digits years (I don't really understand what is meant by "by mutual agreement"): is this something in use today and by whom? Who needs six-digits years and <i>only</i> six digit years? I mean: if you're projecting stuff in the future (like, say, continental drift), you'll be stuff at year 99999 and have the exact same problem of wrapping around back to zero when you'd need year 1000000 no?<p>Or is it "infinite": as in, the spec allows for 8-digits years, 10, etc.?
RE time standards, I always thought it was interesting how WHATWG took a subset of ISO 8601 since ISO went off the rails wrt poorly defined complexity.<p><a href="https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#dates-and-times" rel="nofollow">https://html.spec.whatwg.org/multipage/common-microsyntaxes....</a>
Does anyone know of a website that lets you paste in date strings and it will show you all the possible formats they adhere to along with their format strings?<p>I often come across a string and don’t recognize the format and would love to just supply a bunch of examples and make a best guess.
<a href="https://datatracker.ietf.org/doc/html/rfc3339" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc3339</a> says that rfc339 is a"profile of iso8601" -- shouldn't it be a true subset?<p>Also, I read through that RFC several times and didn't find where it allows replacing 'Z' with space. Can anyone else find it?
The one big failure of RFC 3339 is that it doesn't specify the actual rules for the separator:<p><pre><code> Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
</code></pre>
Is separating it by a tab valid? A tilde? An underscore, as this website shows? Since this is so underspecified, there will be receivers that accept only T, and others that accept the T and some arbitrarily chosen character set. The ABNF only allows T.<p>I don't know how a standard that was specifically written to resolve the issues resulting from such ambiguities ended up with such a crucial issue.
Is the timezone necessary to be compliant? My favorite ISO 8601 format is "%Y%M%DT%h%m%s%", but the table includes a "−Z" on the end and the "Now" column evaluates this as my current timezone.<p>It says the list isn't exhaustive, but I'm just curious how often others actually embed the timezone rather than just passing around UTC.
As someone who frequently works with datetime data, I always felt that in the format YYYY-MM-DDTHH:mm±ZZ:ZZ, it should read "this local time plus the timezone offset gives you utc", not " utc plus the timezone offset gives you this local time", so basically invert the signal from how it is now.
In short, RFC 3339 has all the useful formats we think of when we invoke ISO 8601. The ISO standard has those too, as well as a seemingly endless list of additional obscure and esoteric formats almost no one uses.
All this just makes it clear to me that we need a time standard which addresses all the problems and of ISO8601. It’ll be painful until it’s universally adopted, but once it is we’ll be in timekeeping heaven.
I like the concept of ISOs in general, but I personally prefer RFC 3339. The space makes it so much easier to read at a glance, and I can't imagine it makes parsing much different algorithmically?
do you now whats ridiculous? that we germans (and europeans) also use the iso 8601 but it's still allowed to use din 5008 and the european date and time notations... WHY???
it's so stupid to use dd.MM.yyyy, it's worse in every way to yyyy-MM-dd. worse than that the old notation is preferred in most official documents..... WHY....