> This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename.
My issue is with:
> Simplified, the core date format looks like this: yyyy-mm-dd hh:mm:ss
Here are the examples at https://en.wikipedia.org/wiki/ISO_8601
2021-02-26T06:22:59+00:00
2021-02-26T06:22:59Z
20210226T062259Z
Note the "T" instead of a space between the date and time? That's what the spec says: https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_tim... . "Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339."Note the optional use of "-" and ":"? That's "basic" vs. "extended" formats.
Plus the optional timezone specifier (if not present, assume it's the same timezone).
There's also optional support for microseconds.
> "Here there’s only one correct way to write a date,"
given that there are multiple correct ways, and the way shown wasn't actually ISO 8601 but RFC 3339?
ISO 8601 is a complex specification because of the many different ways to describe times, dates and duration. Don't let that complexity throw you off! The ISO 8601 timestamp format is clean and elegant. These examples will use the widely used ISO 8601 profile known as RFC 3339, which I'll refer to simply as "ISO 8601".
No need for an illusion when synecdoche works.
Example: 20210226-00:01:25 this presents the data in a format I can easily visually parse and also easily search for useful things in log files with.
When parsing such a date I tend to throw out all of the characters, but the 'Zulu' or timezone at the end probably should be parsed in anything that isn't a trivial internal use.
The time is of course no problem but even with "20210226" standalone, I stumble and misread 10 and 22 before noticing that this doesn't parse. If there are more zeros and more 1's or 2's, it gets even worse.
I hate it that the migrations in Rails are numbers only. "db/migrate/20210218125920_add_new_column.rb" is simply not human parseable.
I must say I just saw the dd.mm.yyyy used in Italy, but it seems that a few other countries also use it.
(And EU requires dd/mm/yyyy in "best before" dates.)
Besides this nitpicking, I agree with the author for several years already.
This sounded intriguing, so I checked my fridge, and this doesn't seem to be strictly true. Everything I found used . rather than / as the separator, as is usual here (Austria). But also, some years were YY only. And the eggs are just plain weird: Both the carton and the stamp on the eggs list DD.MM. while the graphic explaining the date stamp uses a DD.MM.YYYY example date.
US dates only make sense if you don't care about the year and are writing on the left most side of a page; that might make sense if ink or paper is at a premium.
The blog post already made this observation, saying that YMD is the only format where the endianness of the date components match the endianness of the numbers; DMY does not have this property. If you wanted to sort dates correctly on the right hand side, you need to write the numbers backwards too, like "72/20/1202".
(I’m not even Christian but I also don’t have a chip on my shoulder and can accept its influence on the world)
So now we have: another calendar, that has a starting year that is defined by subtracting an arbitrary number from a compromise between alledged years some person was born in.
I love how humanity has the capability to invent new things with increasing complexity.
[0] https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesu...