“The elements are always padded to the maximum number of digits. 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.”
UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard.
If you are developing software purely for internal use, that might be okay. But I think it is bad idea if you are developing software for customers, including cloud-based services. There is a good chance at some point you are going to expose your internal timezone to the customer somehow, even by accident. If a customer in another country gets told something like "process X always happens at midnight UTC, and we can't change it", they'll generally be more accepting of that than if you say "process X always happens at midnight at our headquarters timezone, and we can't change it". The second makes you sound like you maybe don't take globalisation completely seriously.
Even developing software purely for internal use, your headquarters timezone may change. Maybe the company gets acquired. Maybe it just decides to move to a lower cost or more business-friendly location (e.g. Oracle's recent relocation from California to Texas). A lot of stuff is going to stick with the old headquarters timezone because changing it is just too hard. But new stuff people may well choose the new headquarters timezone instead. Now you have two standard timezones to deal with!
That's why: just leave everything as UTC internally. Convert to/from user's preferred time zone at time of display and data entry. That works for almost everything, except for applications which need to schedule meetings, work rosters, class timetables, etc. For those kinds of applications, the application needs to actually save the timezone with the data, and support different records belong to different timezones.
It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed.
Things you take for granted are easy to overlook until they break.
You might just have a bunch of files from around the year that you just know won't ever be that close together in time, and which you perhaps also only ever touch manually, not programmatically.
I once chaired a smallish organization, and I used to name the minutes of meeting files with ISO 8601 style. If you have a dozen or so files from throughout the year, having them reliably sorted can make them easier to find, but there's never a problem with time zones or basically anything with granularity greater than a day.
Usually, if you've got a situation where you need to worry about time zones or DST, identifying things with year-month-day style timestamps treated as strings would be too low-tech a solution anyway.
(FWIW, the practice of using ISO 8601 didn't last, presumably because non-technical people didn't find them that nice for one reason or another.)
I think it's across the hall from the room for people who configure servers for anything besides UTC.
It's not like it's a default parameter, you would have to explicitly pass zero if you want the "guess base based on prefix" behavior.
I also don't believe that when everything was adopted, that people realized how big a deal it would become for software, and systems driven by software.
Every leap second, factories shut down. Just in case. Every leap second we face the possibility of a large chunk of the Internet going dark like happened in 2012. Computer programmers spend millions of dollars per year in aggregate dealing with the possibility of leap seconds.
All for something that, over thousands of years, won't lead to as big a discrepancy between the Sun and the clock as what we voluntarily do 2x per year for daylight savings time.
Does it make any sense to continue this insanity? Why?
Millions of dollars in aggregate per year? Assuming that’s just the US, with ~4 million working programmers with a median pay of ~$86,000/yr or about $43/hr assuming about 2,000 working hours per year, that’s, if I’m not messing up the math, on the rough order of 1 minute per programmer per year, on the order of a couple hours per programmer per year if you bumped it to hundreds of millions. In either case, its a neglible share of programmer-hours.
Meanwhile leap seconds decrease accuracy when measuring long time periods unless you explicityly remove them again.
there used to be similar problem with alphabet (folder) sorting though, where Windows used to sort letter CH which goes after H in alphabet right within C as if CH didn't exist, but I think they sorted it in recent years, though I use English Windows and still have this issue, it's quite easy for sorting actually since H never follows C in Slovak or Czech language and when they are together they always make letter CH, so it should be easy to fix for sorting file/folder names
orally we use 12 hours time format even in most of the Europe, we just use in digital watch 24hr format
What I do when travelling in Europe[1] is to un-ambuigify the date by replacing the month number with the English month abbreviation: 2021-feb-26. It's non-standard but can't reasonably be misunderstood by a human.
[1] I'm from a European country where the ISO 8601 way of writing dates is common, and more specifically neither the American nor "European" formats are ever used.
Would be interested where anyone encountered issues with ISO8601 dates
"viachodinový" (multihour), "viachlavý" (multiheaded)... in Slovak. Not sure if there are examples in Czech.
Essentially, in Slovak it is impossible to implement algorithmical alphabetical sorting without understanding the language, to determine whether "ch" appears on the word stem boundary. But yeah, you can sort 99.99% of words by assuming it does not... and maybe increase it to 99.9999% by making an exception for words starting with "viac-".
It's the default date format on my PCs, I've used it for decades. I find it hard to understand why eveyone doesn't use it.
Also, if you work for the UN, it's the default date format.
Sorting within a single year will work, sorting multiple years will place the same date adjacent to each other so it makes them easy to compare if you are printing out let's say sales data.
AM/PM thing is silly, but bearable.
Malformed MM[/-.]dd[/-.]yyyy date format is one of the most confusing thing I have ever encountered and it generates serious problems.
I would say that by just existing it create serious problems. You can never be sure if a date if day/month or month/day, this was especially bad from year 01 to 12. During those twelve years I was a date zealot "there can be only ISO 8601".
So do time zones. So do leap seconds. So does the speed of light. I guess deal with it.
None of what you argued negates the post you replied to. He is right after all. Dates within the year are sortable by pretty much any system.
But most of all the format makes ISO 8601 quite easy for Americans to wrap their head around. So maybe stop complaining and look at 8601 as a possible solution to what you consider confusing and problematic.