The article is missing one of the best features of iso 8601: it‘s string form is naturally sortable. You don‘t need any specific logic for sorting, so e.g. your filesystem will automatically sort files correctly if you prefix them with a iso 8601 date.
“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.”
This is my primary reason for advocating yyyy-mm-dd (regardless of including hh:mm:ss) in my work environment. I always feel it's very simple to explain things like "you can sort by name and it's automatically sorted by date" and it's just unbelievable the amount of pushback I get. This coming from users having trouble finding files from a certain time period, as their timestamps might be different due to copying/modifying. Also easy to convert to INT (i.e. yyyymmdd/20210226) for use as a partition key or FK for a date dimension.
Same here. Even when it's just a folder with a document that has multiple revisions. And especially around this time of year (near the end/beginning of the year).
> 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.
In many contexts that doesn't really matter. Sure, from a programmer point of view that's a problem because there are potential cases with incorrect or ambiguous behaviour, but being able to sort files by date could be useful in cases where that level of correctness and granularity don't matter.
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.)
Which is a side effect of being consistent with the way we write all other numbers, with the value represented by each digit declining as we go left to right.
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?
> Computer programmers spend millions of dollars per year in aggregate dealing with the possibility of leap seconds.
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.
Accuracy of what? For 12:00 to be at noon on average? That's what timezones are for and they also already change. Just add leap seconds to the timezone offset instead.
Meanwhile leap seconds decrease accuracy when measuring long time periods unless you explicityly remove them again.
They have. There are even different variants of human/version sort. They are of course not as straight forward as a simple lexicographical sort so not everything is going to implement one.
that's reason I switched to ISO 8601 in my folders structure decades ago, obviously can't use it in regular documents/communication in Europe
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
> obviously can't use it in regular documents/communication in Europe
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.
English Windows applies English sorting rules, whereby CH is not a separate letter. It is not easy at all, different languages have different rules, including multiple passes over the input (e.g. the first for letters and the second for accents), even some of them left-to-right and some right-to-left.
If document didn't have specified time format, I never had issues using YYYY-mm-dd from ISO 8601. And the ones that had specified time format were upfront about expected format, so...
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-".
The standard American date format (MM/dd/yyyy) also somewhat has this property for a limited number of use cases.
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.
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".
I think it makes sense only in the fact that we write it how we say it
out loud - "February 26th, 2021." It is just another convention, albeit inconvenient for computers. I doubt the british way of saying "26th of February" was done intentionally to aid sorting...
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.
Tangentially related: I hate GNOME's approach at configuring formats.
In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system.
Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator.
You can have sane dates, but then you have AM/PM in the clock. You can have 24h clock, but then you have a comma as decimal separator, etc.
Can we add a country "Saneland" with the sensible options for all fields? cause that's where I want to be from. Saneland: the imaginary place where we use reasonable standards and things work.
I don't use GNOME, so I can't say exactly how it configures those formats, but from the rest of the discussion it seems to just set the locale, probably via LC_ALL. But you can set the various settings individually.
On my Debian system (KDE) that works for what you asked for. LC_MEASUREMENT="en_DK.UTF-8" sets SI units, LC_NUMERIC="en_US.UTF-8" sets dot as decimal separator, and LC_TIME="en_CA.UTF-8" sets ISO 8601 dates and times with 24H format. LC_ALL being left undefined is important, it will override the rest.
The process for updating your locales will vary depending on your distro. But even if GNOME doesn't allow it you should be able to use the terminal.
I open a new terminal and tab my way to the file I want because it's quicker and less mentally-demanding than solving Gnome's UI puzzles. At least I used to until I had enough and switched to a different file manager.
en-se is slightly closer, as it has an ISO 8601 date, but like en-dk it still has a comma decimal separator, and the clock has a dot separator (13.49).
An artificial en-xi or similar is probably best: take en-ie, and just change the short date format.
That reflects (supposedly) the official standard, but even on government forms DD-MM-YYYY or DD.MM.YYYY is used. I have never seen the ISO format used outside computer systems, unlike in Sweden where it's commonplace.
It's inconsistent with da_DK, which uses DD-MM-YYYY.
But there's already the decimal separator bug (writing English? dot, writing Danish? comma).
% en_DK is used outside Denmark, as some sort of generic continental
% European English locale.
And that's the nasty hack -- this should be defined in en_EU or similar.
You can mix and match. Unset LC_ALL, and set the following: LC_MEASUREMENT="en_DK.UTF-8" sets SI units, LC_NUMERIC="en_US.UTF-8" sets dot as decimal separator, and LC_TIME="en_CA.UTF-8" sets ISO 8601 dates and times with 24H format.
But there should definitely be a saneland locale. "en_SANE.UTF-8".
At the risk of nitpicking, I prefer RFC 3339, which is a profile of ISO 8601. ISO 8601 provides room for things you typically don't want, e.g. dropping time zone offsets.
While I'm typing this I realise that I've never actually read the ISO 8601 spec, like probably most people here, because it's not free. I cannot even be sure it really exists.
Yes, and I've read the drafts of ISO 8601-1:2019 and 8601-2:2019. But can I rely on them? They were published in 2016. What has changed between then and the official release in 2019?
Also, neither RFC3339 nor Wikipedia discuss features like open-ended time intervals. They are in the draft, but did they make the final cut? And in what form? No idea...
The closest I've found to "official" documentation of the 2019 update is a short summary of the changes, hosted by Library of Congress[1]. Which is nice to have, but I sure wish the real standard was public.
> never actually read the ISO 8601 spec ... because it's not free
I was very surprised to discover this. Why are they charging money for the specification of a date format? I would expect standards like these to be published in public domain.
Aside from the fact that you are conflating copyright with price, note that many standards organizations charge money for copies of their standards documents.
ISO charges roughly 20 times the price of a paperback book for a 33 page document. You can buy BS/ISO 8601-1:2019 from the BSI for an even more exorbitant £246. Standards Australia will sell the older 2007 version to you for a mere AUD165.
But this is not special. All standards documents cost money from these organizations, from dates and times to electrical plugs. Treasure the fact that you can (for example) get (some) ECMA standards from ECMA for free. It isn't the norm.
ISO finances their operations by selling documentation, subscription from members, etc. The point of ISO standards is to facilitate international trade. The intended audience for these standards are large multinational companies.
Pretty much all the standards bodies I know of are financed through sales of the standards documents. It's not a bad system, in the end the commercial entities who end up needing them most pay for their development and upkeep.
I have read the actual ISO 8601 spec. It is somewhat typical wall of prose ISO standard that contains meaningful conformance distinctions which depend on two words in the middle of 10+ line paragraph.
For me, more significant reason to prefer RFC 3339 constrained profile is that ISO 8601 does not only mean YYYY-MM-DDTHH:MM:SS.sss but also includes bunch of alternate syntaxes like YYYY-DDD. And I have one big issue with RFC3339: there are cases when the "don't care about timezone" ISO 8601 syntax is actually useful.
> While I'm typing this I realise that I've never actually read the ISO 8601 spec, like probably most people here, because it's not free. I cannot even be sure it really exists.
Always wondered about this too. How can people implement a standard if they can't freely access and reference it? It's the 21st century. Why can't they just publish the document on the internet just like the IETF does?
> How can people implement a standard if they can't freely access and reference it?
They pay for it, out of the money they expect to make on the implementation.
It's a little problematic for free implementations, but then for most standards much less so than the engineering going into the implementation which has an (opportunity, if nothing else) cost.
The ISO8601 yyyy-mm-dd format is fine and intuitive. What trips people up all the time is the ISO8601 yyyy-www-d format (year-week-weekday)[1]. People who know it well can appreciate the benefits. But it's deeply unintuitive to people who encounter it for the first time, that the year in yyyy-www-d sometimes differes from the year in the yyyy-mm-dd format. And a perpetual source of bugs when inexperienced devs use the wrong year specifier (https://news.ycombinator.com/item?id=18762988).
The biggest wart in the spec IMO is the (optional) T in 2021-02-26T09:24, which makes the datetime format much harder to read for humans.
The "week date" format (yyyy-www-d) in ISO8601 is IMHO why it's usually better to refer to RFC3339, which doesn't allow the week date format.
So many people are unaware that the ISO8601 format allows "week date" and/or don't understand its quirks, and articles like this one, which don't even mention that ISO8601 dates can appear in this format, compound the problem.
The "Week" format is great for planning purposes, because it allows a granularity between days and months with another whole number per year. Saying that a task will begin 2021-W08 and then defining the start of the week (ISO8601 says its a Monday), tells you exactly when it will start.
Saying the task is 2021-W08/P4D tells you exactly when it starts and how long it will take. Or P4D/2021-02-25 says the same thing but in terms of when it will end.
It does mention it though, FTA:
...and a calendar where the year is separated not by months but by weeks, which is used in finances, but here we’re only interested in the basics.
Those two LoC links are for the 2016 draft of the 2019 specification. Hard to say how much it varies. And the ISO link only lets you see the definition of terms and symbols. Actual syntax details are all locked up.
https://www.loc.gov/standards/datetime/
seems to be a usable summary of the 2019 spec, though being just a summary means it probably excludes discussion of finer details and considerations which might be important at times.
The real advantage is that Azure and AWS and every other US-centric cloud service insists on showing me that something happened on the 3/11/2021.
It's a wild guess to figure out if that is the 11th of March or the 3rd of November.
Unless there's also another date with a number higher than 12 in it, there is no way to tell. None. None whatsoever.
For US staff with US regional settings, it's always obvious which date is correct. That is the one single case where there is no confusion. This works as expected for just 4% of the world population, but it is those 4% of the world that get to decide the date format.
It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them... only the other 96% of the planet.
> It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them...
As an American I can fully confirm that 3/11/2011 is obnoxiously ambiguous. It affects us. But most Americans (particularly outside of science / engineering fields) are too thick-headed to recognize the problem or think about ways to improve it.
So I do what I can. I don't even ask what time format something belongs in. I just write ISO8601 by default. If someone complains then I point them to the international standard and ask whether we want to be an internationally standards-compliant company.
One manager said that our customers aren't international. It was a reasoned argument and I like having customers. But all others drop the argument at "international company" and "standards-compliant"
>So I do what I can. I don't even ask what time format something belongs in. I just write ISO8601 by default. If someone complains then I point them to the international standard and ask whether we want to be an internationally standards-compliant company.
This is my approach as well. I've never gotten a complaint about it, which proves to me that the format is understandable AND unambiguous.
How can you take an international standard seriously when it is based on the number of years since some prophet of some specific religion was thought to be born?
Can you suggest a better alternative which you would take seriously? A Kelvin-like year based on the approximate date of the Big Bang (as CE/BCE is based on an approximate year)? Logical but unwieldy.
I have indeed done the former when discussing why I use meters instead of feet.
The latter was an ice rink whose customers are very physically local. Local teams do compete internationally but the ice rink itself isn't an international org.
Yup. I hate // AM/PM formats with a passion. Doesn't help that I work with UK teams now, and their "natural" date format is 3/11/2021, with meaning of 3 and 11 reversed to what they'd mean for Americans...
sigh.
ISO 8601 everything. I'm religious about it. I write it in messages, on government forms, anything that doesn't force me to use a different format. On a bit of my insistence, we use ISO 8601 notation for all dates at home. I think the benefit is quite obvious once one starts using it.
Can still be ambiguous because "list." means October in Croatian but November in Czech. Also, "lip." is July in Polish but June in Croatian and "srp." Is July in Croatian but August in Slovak.
Maybe it's just Croatian that's ruining it for everyone.
That's missing the point of pressuring the other side to adopt ISO 8601.
(And in general case, of electronic documents with wider audience, using 3/Nov/2021 excludes people who don't know English (or the language in which you encoded the name of the month).)
The vast majority of documents are written in a language anyway so you can safely encode the date in it. Does any other language even have two different, conflicting date formats like that?
English is the only one with conflicting date formats I can think of (US vs UK), but in case of government and corporate documents, those are sometimes bilingual - with form labels in the primary language having a small-font translation to English below.
(Real use case: I recently sent a Polish equivalent of OSHA form to my line manager in UK, and I used a bilingual version. As you can imagine, I set the example by filling my part of the document using ISO 8601 for dates, so that once the document returns to the Polish corporate office, there won't be any possible confusions.)
On government forms (and other paper forms), I use 3/11/2021. It's unambiguous; nobody would expect it to mean anything other than "3rd of November of 2021". The ambiguity only happens once you add the Internet to the mix, and even then, only in English-language websites (I wouldn't expect anything other than DD/MM/YYYY on Portuguese-language websites, and the same probably applies to most other languages).
You don't need the Internet for ambiguity to occur, you only need to go international. It may be because you travel, or work with foreigners, or handle mail/packages to/from abroad. Or use any kind of software, because unless you live in the US, almost all software you use is made by foreigners in a foreign country.
In a globalized economy, local date formats are just one of those annoyances that serve no benefit, cause everyone unnecessary hassle, occasionally causes expensive errors, and that should have long ago been replaced with an international standard.
Format the date on the frontend using date.toLocaleDateString() and let the browsers locale do the work for you (assuming you’re in JS and on the web).
No. The computer cannot magically detect the preferences of an actual user. This is a kind of "90% solution" that excludes people whose locale setting doesn't match their preferences, which is arguably quite common. Reasons include buying your OS/computer from abroad, or one that was imported and resold, getting a work machine set up for a different country, not knowing how to fix locale up yourself, traveling (localizing websites based on user's location is idiotic, but it keeps happening)....
What developers also suck at, in practice, is data-typing their output properly. If I see 5/2/11 on a US site while using my work laptop, I can't be sure whether it's the US notation written by the author, or date localized by my browser for UK format, which has the day and month reversed. I can't tell if the date is localized or not, or how it was generated.
Just say no to all that complexity, and use ISO 8601 everywhere. My controversial view here is: in this industry, we're still in a privileged position to force the entire world to standardize on the important things, like dates and times. So let's do so, and get everyone on board with an international standard, instead of just unwittingly pushing the USA defaults. We are pushing things, that comes with "software eating the world". So let's push things that make sense.
Okay, well I'm pretty sure for most apps I've worked on this has been fine according to business requirements and solved the problem of our users. Do you have statistics on which users have their locale's set wrongly and can you explain why the browser provides this functionality? Maybe you should campaign for it to be removed on their mailing lists?
Also, should you want to change the locale (via a preference or override somehow), in most browsers you can pass it as the first parameter.
I think your view is very much a classic developers view - sure it would be nice to be able to dictate software requirements to businesses but you are probably going to be quite angry as your version of right and someone else's are going to be different.
That's why we have international standards. So that 1 version of right and all others are wrong. And no matter how arrogant it might seem, at least for computing use cases, ISO 8601 is right and other date formats are wrong.
There are absolutely no usecases where the US date format makes sense. No, having it written in the order you prefer to pronounce it is not an argument. Especially not in the language where you have to learn spelling. It is just what US people are used to.
I don’t disagree, in an ideal world great, let’s get everyone to change to ISO8601. I’m a big fan. However until developers become in charge of all the decisions (imagine!) I’ve suggested a reasonable solution that most people can use to format dates in 99% of users locales with too much hassle. There are more interesting bridges to die on.
> However until developers become in charge of all the decisions (imagine!)
The thing is, we sort of are! As I mentioned upthread, notation and language are being strongly influenced by increased use of software in every facet of our lives. The way people note numbers, dates, express search terms, etc. are all impacted by what the software accepts and displays by default. We have an opportunity here to push for positive cultural change around international standardization, so let's make good use of it, instead of squandering it by just implementing whatever seems to resemble the local status quo the most.
Short of stepping through the JavaScript line-by-line, how do you tell the difference between these two dates?
3/11/2021
3/11/2021
The difference is one was formatted incorrectly, and the other was formatted correctly. One is 2021-03-11, the other is 2021-11-03.
Even having been told that there's a difference, you cannot know which is which.
Even if you think you know because you found an unambigious date like 31/11/2021 somewhere, you still shouldn't be confident because there are many sources of dates, and they're formatted by many different pieces of code. Some may be doing the "right" thing, some may be using US formatting. A complex web application like the Azure or AWS consoles might have literally thousands of sources of dates formatted by a thousand different pieces of code.
Before the 12th of the month, they're all totally and utterly useless for 96% of the world unless they use ISO 8601.
BTW: I just tested this with the Azure portal by clicking through some Log Analytics related things. I got it to show me 3 different date formats, 2 of which would have been ambiguous earlier in the month, and one of which changed between two tenants. So even if you learn which parts of the UI you can trust to be correct, switching tenants will invalidate your experience.
You're making the assumption that users know YYYY-MM-DD is the date format and not YYYY-DD-MM. I bet if you asked non-developers the answers you would get would be pretty random, probably more errors than the locale on their machine.
Wikipedia claims [0] that is the date format in Kazakhstan, but only for the Kazakh language, not for Russian. (Maybe there is someone here from Kazakhstan who can confirm if that is true or not.)
A lot of companies don't have any employees in Kazakhstan (which means they can ignore this for internal systems); and many companies wouldn't have any customers there either (which means they can ignore it for external systems as well).
It took many decades to widely adopt UTF-8. I think that one of the reasons was that US companies did not really care about character encodings, as it's not something they have to often deal with. Even today managing multiple keyboard layouts is a pain in most operating systems, it's buggy, it does not have enough configuration options, it's not convenient. Probably because most US developers never tried to use that functionality.
Mac Firefox and Mac Chrome both break a bunch of keyboard shortcuts if you use a non-US-ANSI keyboard. Safari handles alternate layouts correctly.
Just yesterday I learned that on an ISO Spanish keyboard, both of those browsers will pop up a help menu for ⌘⇧7. The logic goes: ⇧7 means / on a Spanish ISO keyboard, and ⇧/ means ? on a US-ANSI keyboard, therefore ⌘⇧7 is by the transitive property of inter-layout shift functions equivalent to ⌘?, which is the shortcut for opening the help menu.
They don't pop open the help menu if you press ⌘⇧', the actual ISO Spanish layout way to type ⌘?
I use EurKey [0] (I think this was actually recommended to me on HN) so I have easy "AltGr" access to German characters like öüß. Sadly some tools (most notably Microsoft’s) have hardcoded shortcuts for some of those, which is really annoying.
I use the Canadian English layout on macOS for most of the time, if I need to enter accented letters, I can just hold down a normal letter (A) then select an accented one from the popup (Å). The international English layout works the same way if I remember correctly.
Mac everything breaks for me on a UK Mac when using an ISO keyboard rather than their non-standard ISO layout.
Page down only sometimes works, and Command+~ to switch same app Windows works in some apps and not others. It's a bit of a train wreck when you want to get rid of their pointless keys.
The built-in apps seem to handle it pretty well (ex. the dictionary app has ⌘Ä / ⌘Ö shortcuts when set to Swedish). 3rd party apps often don't care and it gets worse the more you move away from plain QWERTY.
Although macOS is good in the aspect that combinations akin to AltGr on PCs aren't unique to non-US layouts. I've seen programmers assume it's safe to assign shortcuts to Ctrl-Alt (which simulates AltGr), making it impossible to enter certain characters. Not surprising, as it's not used on the US layout (just as there's no extra key next to the left Shift).
Not only Firefox. Cmd-/ is also a very common "toggle line comment" shortcut. I think it's the default on Sublime and IntelliJ, and any editor that offers a "Sublime compatible" preset (like VS code) imitate that. Of course, such a shortcut broken out-of-the-box for any keyboard layout that lacks a / key.
Yeah, Sublime copied this shortcut (like most of its features) from TextMate, and it has since spread widely.
Amusingly, TextMate's author and many early users were European programmers with US-ANSI keyboards (because the various European layouts are just too painful for writing code in ASCII-based programming languages).
But contrary to the date issue, you could at least make a case for using ASCII everywhere. I'm not saying it has no downsides (e.g information density). It may also be unrealistic and culturally insensitive, but there are very clear upsides as well. Not so with the U.S date format. It's just bad.
My wife recently bought by mistake a keyboard whose layout I couldn't figure out. It took me a full 5 minutes to even get to the correct place where I could configure keyboard layouts under Windows 10 settings. Then I had to choose the keyboard layout I wanted to add. This was a list in a dropdown with hundreds of options without an image of what each layout looks like so I could not check which option matched the keyboard in front of me. There was not even an input field where I could test the chosen layout, I had to switch back and forth from the Notepad. After many tries, I finally got it right: Portuguese. Completely by trial and error.
I like the method that Mac OS uses to detect the layout of a newly connected keyboard. It brings up a dialog asking the user to press specific keys (something like "type the | character") until there is only one possible layout that would generate the observed keycodes for the characters in question.
Same method as certain mainstream Linux distros has been using the last few years? Or has Mac been doing this for even longer (I cannot remember how it worked back in 2012, the last time I used Mac.)
Another example of obnoxious American attitude: the TZ variable in POSIX.
TZ=UTC+8. Is your system now set to the timezone UTC+8? No, it's set to UTC-8. Why? I don't know, but I suspect the people who developed this convention, who lived in the US, just didn't want to type a minus.
The TZ format counts how many hours behind UTC you are (how many hours should you add to get UTC time). The ISO format counts how many hours ahead of UTC you are. Neither choice is inherently correct, but the discrepancy is pretty annoying.
It is exaclty this attitude what makes the datetime format in Golang extremely difficult to use. I always have to double check my formatting. I like the basic idea very much, but its logic only works for 'local' Americans.
The reference time used in the layouts is the specific time:
Mon Jan 2 15:04:05 MST 2006
which is Unix time 1136239445. Since MST is GMT-0700, the reference time can be thought of as
01/02 03:04:05PM '06 -0700`
Golang was not meant to become a big international language from the start? Just a fun internal Google project ;-)
Another great thing about 2021-03-11 is that, even putting aside its technical advantages, it is (probably) intuitively understandable to any literate person even if they have never seen it before and, most importantly, it is almost immune from confusion because (hopefully) nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American intuitive expectation of month coming before day, and the Worldwide expectation of time units being displayed in a logical order.
I don't think it's fair to assume that the people choosing the WTF option would not have interpreted the format correctly if they had to pick an actual interpretation.
yyyy.dd.mm. (but not with hyphens!) are commonly used for all the languages where their grammar and word order means that the spoken way to say dates is like "twothousandtwentieth year's first march".
> it is almost immune from confusion because (hopefully) nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American intuitive expectation of month coming before day,
I disagree. (Or, perhaps I’m insane...)
I paused when coming across the ANSI version in the article as I couldn’t tell whether it was YYYY-MM-DD or YYYY-DD-MM.
I thought there was a typo or something.
I’ve nothing against the standard, but as Americans have no ‘intuitive’ reason to sort the fields by significance, it is natural for some to incorrectly assume the ANSI version is just the American version written backwards.
Tangent, but I do like the space-efficiency in some cases for Chinese/Japanese characters that make them great for status bars and terminal prompts.
E.g. a single character to unambiguously denote weekday, window layout (全／広／高）, and others. Renders everywhere as long as you have a decent CJK font. Bonus: looks a lot less stupid than emojis.
My desktop terminal prompt right now shows [金 19:58:22] - just a single character and as long as it's < 7d ago it's unambiguous what time and day a command exited in case I forget.
> My desktop terminal prompt right now shows [金 19:58:22] - just a single character and as long as it's < 7d ago it's unambiguous what time and day a command exited in case I forget.
You're a bit cheating there :) It's one character that takes up 2 columns.
You could get away with using the first 2 characters from the English names as they are unique. But I know that in English that's unusual but for example in German, the 2 letter abbreviation are the standard ones.
You say weekday, but Google translate and Wikipedia say that 金 means gold?
The planet-weekday combination is harder to see in English than e.g. in Romance languages like French because English derived its planet names from Roman gods, but its weekday names from Norse gods (e.g. Friday comes from Freya). German is similar, having Freitag for Friday (again from Freya) and Donnerstag for Thursday (from Thor).
Slightly off, but this is fun, so let me expand (along with a minor correction):
The days of the week were named after the seven classical planets of astrology (by the Romans, who in turn named the seven classical planets, and hence the days, after Roman deities).
The names were taken up by speakers of Germanic languages, and eventually underwent semantic loan translation: Germanic deities were substituted for the Roman ones (with the exception of Saturday). Some people say that the Germanic deities themselves were culturally identified as one and the same as the Roman deities, but we probably won't ever know for sure (interpretatio germanica, analogously to the interpretatio graeca, the identification of Egyptian, Roman and Greek deities [1]).
And now, a minor correction: The day of Venus, Friday bears the name of the Germanic goddess Frigg, who is not the same as the Norse goddess Freyja. The meeting of the two characters, in a debate against Loki, is described in the Poetic Edda [2].
Maybe a bit cheating - but it's nice with the consistency, and visually it becomes a lot more clear and immediate at least for me.
"金" would be short for "金曜日", a common way to abbreviate weekday names in calendars etc and yes, Friday is indeed the day of gold - I like to imagine it's the old pay day for workers maybe? :D
the upside of Canada's incredibly stupid date formats is that nobody complains when you try to use ISO8601 format instead, we're all somewhat used to date formatting being flexible.
My american users get very angry when they see a date that isn't in dd/mm/yy format.
Corrections: Most but not all government forms in Canada use yyyy-mm-dd format, which is a positive change. But indeed we are used to living in a mishmash of American, European, and ISO influences. Americans might get angry if you don't use mm/dd/yy format; I'm not aware of them being attached to dd/mm/yy.
It’s a representation of how us Americans talk - we rarely say 26th of February and instead say February 26 - and if necessary tack on the year. It feels exceptionally awkward to say 26 February, thought saying “twenty twenty one February 26” sounds very strange, too.
But people are very good at verbally saying different than is written.
You could even say "The Fourth" and almost all Americans would understand. I think that's why; [begin speculation] it's such an exceptional date it necessitates saying it differently.
It doesn't help at all if they try to localize it because then it's just 11/3/2021 which is equally confusing and you have no idea if they're using your local format or theirs. Any what's your local format? The country you're in or the country you were in when you signed up for the service or the country your VPN server is in? Internet services really need to stop using these stupid mistake-inducing, time wasting date formats. People might have a sense of unfamiliarity seeing ISO8601 format but they can still understand it.
I use ISO8601 dates everywhere possible. Paper forms in the real world where people look at me strangely, invoices, file names which is really handy for sorting, my personal todo lists, everything.
I don't know, I'm German and deal with US folks a lot, for me it's like this: Date written with slashes or dashes (3/11/2021 or 3-11-2021) implies US-based month/day/year. Date written with dashes and the year first and zero-padding (2021-03-11) implies year-month-day, aka ISO8601. Date written with dots and without padding (11.3.2021) implies my native format, day.month.year.
UK/Ireland are pretty interchangeable about the seperators, but I'd guess D/M/Y has a strong lead over second place d/m/y, while d.m.y is trailing in last.
I think your response to these language quirks can vary depending on your familiarity with the language:
- to an outsider, learning that a concept exists: “that is an interesting thing”
- to a beginner, trying to construct the right form or to detect it in quickly spoken speech: “this is annoying and I hate it”
- to an intermediate speaker and beyond: “eh it’s maybe weird but whatever”
I used to hate noun declension in Czech as a beginner (7 cases x plural/singular = 14 forms a noun can take[0]) because it’s intimidating and unintuitive for an English speaker, but now I’m at the “meh” stage.
[0] - then consider that there are 3 genders, and each gender has a handful of “models” (patterns for declining words that look a certain way), and also a bunch of exceptions. Not the hardest thing in the world, for sure. But it’s definitely a bit of a pain
I’ve always thought it’s interesting how the languages like that (most of the Romance languages have declensions and such) add error detection and even correction - you can figure out parts that are missing or got changed by the lack of agreement between the various forms.
You may not be able to correct it from the Information available but you’ll know something went wrong.
This explains, to me, at least, the whole "four score and seven years ago" speech. I always wondered the reason behind such a silly way of presenting a number, I just figured it was archaic.
Same deal in Slovenian. Twenty one is written as "enaindvajset" ("ena" - one, "in" - and, "dvajset" - twenty) which is the same format as used in German ("einundzwanzig").
The AWS console is absolutely terrible for this, not just because it disobeys my preferred date format but because it's not even internally consistent. sometimes it converts timestamps to my local timezone, sometimes it displays them in UTC, sometimes it displays them in ISO8601 format, sometimes it displays them in US format.
The best part is when someone tried to make it work for the other 96% of the world but failed for 2% of the dates (probably because the other locales got less testing, again very US centric), so one ends up with mixed US/EU dates (the latter often also uses / as a separator, as . is only used in some EU countries).
It's so much fun trying to retrospectively correlate fatal incident data and failing to make sense of anything because some dates are inconsistent. Of course those dates are all the ambiguous kind, otherwise it wouldn't be -that- hilarious /s.
On presentations for projects I tend to add a couple of 'fun' slides. When said projects involve people in the USA, I (almost always) include the XKCD ISO 8601 cartoon:
How does it "fail"? Taiwan has different year numbers but they are sufficiently offset to avoid disambiguity and IME people can read normal years just fine. Anyway, the year-month-day order seems to be the same.
It's more obnoxious to be lectured by people who think "June 3rd, 2021" isn't shorthand for "AD 2021 June 3rd", which is proper logical and sorting order.
> It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them... only the other 96% of the planet.
I’m not going to comment on the author, though I will acknowledge the abrasive, unhealthy attitude.
Anyway, no. I don’t think there’s a clear “American” standard. Maybe there once was, but I’d just see a pile of numbers these days. It’s hostile to the consumer as it inherently leaves some uncertainty of how it should be consumed.
I will say, and maybe this is American - but I don’t think it is - that I often see dates formatted unambiguously as, e.g. March 11, 2021.
Is that also how you’d say it? If verbally asked what tomorrow is would you say “twenty seven February” or “twenty seventh February” or “twenty seventh of February”? Americans normally would say “February twenty seventh”.
They are so convenient. Ever stored a tuple of two datetimes to model a time interval? E.g. a meeting that takes place on 2021-05-01T12:00:00Z and takes two hours?
Don't! Instead, store it as an interval: "2021-05-01T12:00:00Z/P2H"
Or are you creating an API where a duration or a time interval is expected? E.g. "give me all sales in this time period..."
Using time intervals for that makes it so much more easy for people to code against it and execute manual queries.
I agree it's undervalued. Sadly too few people are aware that a standard notation for time intervals even exists, and external software support is very sparse (e.g. lacking in Pandas, R, most SQL implementations). Which leads to too many devs rolling their own buggy solutions for datetime arithmetic.
There's another aspect you may not know about: It's close to how it's done in chinese, which is 2021年3月17日. They use different separators (the chinese words for year, month and day), but it's close enough.
Given that china is the country with the largest population it may not be a bad idea to use something a large number of people will easily understand.
Where’s the logical fallacy? More people natively speak Chinese than any other language in the world. If you want to maximize the exposure of your ideas, it’s only logical to render them in Chinese. It’s the same reason I prefer to distribute applications over the web.
> Why would that matter? Arguably the ideal lingua franca should have no native speakers at all as those have an unfair advantage.
I share your vision of an explicitly taught universal language which gives no group or individual an unfair advantage. We obviously need more equality in the world.
From the perspective of trying to maximize how many people with whom you are able to communicate, however, on a practical basis it matters little whether or not they are native speakers.
A larger percentage of mandarin speakers are native mandarin speakers than the equivalent statistic for English. 918 million native mandarin speakers, 310 million native English speakers. Native speakers are generally better at understand the nuances of language than non-native speakers.
This is actually not wrong. China is already very important, and its influence is going to grow. Speaking and understanding Chinese well is a competitive advantage.
I've learned Chinese for fun. It's great that I can now read a few more Go/C++ READMEs on GitHub, but other than that, I can't imagine what advantage it has? Maybe there'd be one if I came from a poorer manufacturing country?
even China commentators in Western media are often completely clueless about the language. If these jobs don't require Chinese fluency, then which ones do? And even then, it'd be much easier to employ the many, many native speakers who emigrate from the PRC.
Actually, many Chinese people mock western commentators for how bad their takes are. Those commentators often have a superficial or highly western-centric understanding of things in China, resulting in wrong or incomplete interpretations. Lack of Chinese language understanding is a contributing factor.
That doesn't stop those commentators from getting lucrative jobs. Apparently, western audiences don't care to verify whether what commentators say are accurate, or audiences just don't care whether it's accurate. There are no consequences to even years of inaccurate commenting. So I guess if you have no professional pride, then yes you can get away with not learning Chinese.
I agree. I was applying logic consistently. With 918 million native speakers, Mandarin is the most natively spoken language in the world by at least 2x the runner up.
I teach my 9-yo daughter to write dates in ISO 8601 format whenever permissible, too. I tell her that all other formats that her school teaches her are just nonsense and wrong.
Except `YYYY-MM-DD HH:MM:SS` is not the ISO 8601 date format, `YYYY-MM-DDTHH:MM:SS` is (note the T). Replacing the T with a space is a RFC3339 extension.
The real purpose of endianness which is missed here is the ability to sort. Sorting a list of iso8601 dates alphabetically means sorting them chronologically too.
> 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
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).
Spot on: I came here to make this comment about ISO 8601 vs. RFC 3339 and point-out that "European format" is a generalisation, not a rule: Lithuania [1] and Sweden use the ISO 8601 for date representation, and Portugal and Spain uses dd/mm/yyyy.
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.
> (And EU requires dd/mm/yyyy in "best before" dates.)
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.
I loath the T and Z characters, so respectively I use a single dash (Between the date and time) and no Z; for time I often leave in the colons (:).
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.
I find it impressing that you can easily parse 20210226-00:01:25.
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.
When I visited China, I saw 11-digit phone numbers commonly written without any punctuation or spaces: like 12020569031. I guess you can get used to it.
Yes, technically there are some edge cases where you can write things differently (apart from what you mentioned, one is, for example, writing the UTC time zone by Z vs +00:00 and another is adding additional precision to the date), but for the end user it's basically the same. Let's not ruin the illusion here :)
There's nothing wrong with leading with something like:
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".
That's also the only time (full) European dates make sense, when writing them on the right hand side of a ledger page so that the exterior of the ledger / book is indexed with the largest components on the edge of the page.
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.
What you said about European dates (e.g. 27/02/2021 today) is not strictly true. The rightmost character is the ones digit of the year, and it is not the largest component. According to your rules, 01/01/2019 would be "larger" than 01/01/2021 because 9 is larger than 1.
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 know you’re not saying you are encouraging it and it’s just a related but of trivia, but I find that hilarious. Because when someone asks “why start there?” the answer “it’s a thousand years before Jesus Christ was born, the millennium heralding his arrival” is better?
(I’m not even Christian but I also don’t have a chip on my shoulder and can accept its influence on the world)
The answer is “because -10000 CE is an approximation of the beginning of human civilisation, using this epoch removes negative year numbers from all historical dates, and it's simple to convert from the ubiquitous CE epoch”.
It's ten thousand years before the assumed (but likely wrong) birthday of Jesus Christ, to have a positive date for all written human history (well, until we find the archives of Atlantis) and an easy round offset for the prevalent human calender in use.
... which is funny, because the gregorian calendar is supposedly based on a compromise between some years that christ was supposedly born in (the chosen year 1 is none of those, according to research, as he was born in 6-4 BC [0]).
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.
Yup. I have a calendar for 12021 hanging in my office, and I very like the sentiment it expresses. I tried to use the Holocene years with other people, but they remain unconvinced.
I use the 2021-02-26 format for every place that asks for a date without a clear format. All legal contracts, forms, email etc, across US and Europe. Never got any trouble for it - it seems people readily understand the format even if they may think it's a bit unusual.
Yeah, I deal with so many different countries that it is a minefield using any other date format than RFC3339/ISO8601. I have been stung by having my birthday month and day inverted a few times when using DD/MM/YYYY format.
I have a question for the timezone crowd: why does the ISO 8601 format include a UTC offset like "+09:00" instead of a more useful region name like "Asia/Tokyo"[0]?
Take for example the timestamp "2025-07-20 13:30:00+09:00":
- If it was supposed to represent a meeting in Asia/Tokyo and that region changes offsets (DST or political reasons), we don't have enough information to update the timestamp because it could also have been Asia/Seoul or other.
- If a leap second is subtracted at 2025-07-20 13:30:01+09:00, we'll see that timestamp twice and it's now ambiguous which moment it refers to.
- If a leap second is added at 2025-07-20 13:29:59.9+09:00, we'll never see that timestamp and now it's not a valid moment anymore.
- Because of the regional offset changes and leap seconds between now and then, I can't reliably subtract that date from any other date to calculate durations.
I'm struggling to think of a situation where this timestamp format is the correct one.
Why don't we have "2025-07-20 13:30:00+09:00[Asia/Tokyo]" or even just "2025-07-20 13:30:00 [Asia/Tokyo]"?
I think because it would defeat the portability of a timestamp because Asia/Tokyo isn't constant and you cannot lookup the offset without relying on external database that takes in ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in zoneinfo changes depending on day of a year, and sometimes even hour of a day, and the database of timezone is constantly updated (latest zoneinfo is version 2021a).
So while having 2021-02-26 18:38:00 Asia/Tokyo as a timestamp would more accurately represent the time, it would create another set of issues, namely requiring a database to look it up, and requiring to keep those database in sync in all systems in the world. Having both may be redundant because in that case you can't still trust the offset.
There are alternative systems such as TAI64[1] based on TAI[2] that are meant to accurately represent the moment in time without being subjected to leap second (only account them on conversion to UTC). The main issue is TAI64 is not really human readable (e.g. @4000000037c219bf2ef02e94) and would still require database of leap seconds to accurately convert back to UTC.
About the TZ database, don't all date lookups require accessing it? If I schedule a meeting in Asia/Tokyo now, and the database tells me it's +09:00, I still have to remember it's Asia/Tokyo because the offset may change 5 minutes before the meeting.
Analyzing the timestamp requires a TZ database, but that's calendars for you; the encoding is not going to change this. We don't actually know when the meeting will take place until it does.
I'm still struggling to come up with a situation where including only the offset is the correct approach, which makes ISO 8601's decision puzzling.
I think the main usage of ISO 8601 was to represent a point in time in UTC for exchange, not a local time plus timezone. When a date such as 2021-02-26 18:38:00+0900 is provided, it did not meant 2021-02-26 18:38:00 in Asia/Tokyo, but meant 2021-02-26 09:38:00 in UTC. e.g., 09:38:00Z and 18:38:00+0900 and 16:38:00+0700 were supposed to be equivalent.
In this case, timezone is external to this format and the timestamp can be calculate back to UTC without relying on zoneinfo (which is very useful for exchange). Any further conversation would be external to this format. e.g., in case of calendar, it's probably more useful to have datetime in local timezone rather than of the other party's timezone so the tuple would be (utc_time, local_tz) rather than (other_localtime, other_tz, local_tz).
The stored offset was just my best guess for what Tokyo's offset will be at that date, according to my current TZ database.
If the database changes, I have to go back and edit my timestamps (!), but I dont know which ones to edit because I didn't keep track of (1) which ones are +09:00 because of Tokyo, as opposed to Seoul, and (2) which ones were created with the old database.
The tz database in itself is a massive project, that only somewhat recently (2011) started being backed by an organization (ICANN, which is not completely uncontroversial), and when ISO 8601 was created, it was still in its infancy. Additionally creating a timezone database from scratch was probably outside the scope of ISO 8601.
You are conflating two separate issues. To address your first issue, ISO 8601 uses numeric time zone offsets because it is simple and reliable. It lets you interpret a timestamp offline, without needing an enormous database of names and rules, and without constant online updates due to political reasons as you said.
Another way to think about it is like this: Suppose right now you schedule a future event that happens at exactly 2025-07-20 13:30:00 in Tokyo time. Then you calculate exactly how many seconds in the future that event is (based on Tokyo's current time zone rules, assuming no political changes), and you start an offline countdown timer that has no Internet connection and no knowledge of time zones. You can think of ISO 8601 as basically this - a way to describe absolute points in global time without references to politically motivated definitions of local time zones.
As for the second issue regarding positive/negative leap seconds, this issue is not unique to ISO 8601. It stems from UTC, and afflicts every popular system for describing time-of-day. If you want to subtract dates reliably to calculate the physical (rather than calendrical) number of seconds, you want to use TAI (Temps Atomique Internationale).
> You can think of ISO 8601 as basically this - a way to describe absolute points in global time without references to politically motivated definitions of local time zones.
But that's TAI. Any calendar is a consensus agreement and amenable to politics (see Samoa skipping a day in 2011 [0], and all the bizarre calendar changes of the 18th century).
ISO 8601 sounds simple and reliable, but only because it refused to adopt most of the human complexity of timezones. Kinda like "extended ASCII", that allowed programmers to pretend just a little longer that all characters can fit in 8-bits. And we don't have a Unicode for dates.
If Tokyo changes their DST rules or leap seconds happen, your simple and reliable offline countdown timer will be wrong. How is that acceptable for a calendar-based (i.e. human) format?
Or if I'm naming my files with ISO 8601 dates and relying on lexicographic sorting (as others in this thread suggested), I'll have gaps or overlaps after DST changes.
Am I crazy? I'm getting lots of disagreement, so I must be doing something wrong, but the more I think about it, the more I believe that ISO 8601 succeeded by stealthily sacrificing correctness.
> ISO 8601 uses numeric time zone offsets because it is simple and reliable.
But it isn't. It's unnecessary complexity because additional numeric zones offer no real information beyond what UTC-only provides when you want to “describe absolute points in global time without references to politically motivated definitions of local time zones.”
> - If it was supposed to represent a meeting in Asia/Tokyo and that region changes offsets (DST or political reasons), we don't have enough information to update the timestamp because it could also have been Asia/Seoul or other.
I don't store timestamps in ISO; I use them for communication, then parse and store them as epoch time. So if the regional offset changes, the epoch time doesn't. In theory, that epoch time is absolute and I can display it localized to anybody's preferred locale later.
In that light, adding/substracting seconds is just adding/subtracting seconds, although I'm usually passing that work off to a date library, which I hope accounts for skipped seconds caused by leap seconds....
For DST shifts and leap second things, aren't certain time strings just as ambiguous with a location-based time zone as they are with an offset?
> For DST shifts and leap second things, aren't certain time strings just as ambiguous with a location-based time zone as they are with an offset?
Good point. I'd argue that location-based time zones make the uncertainty more explicit, but they don't remove the ambiguity.
> epoch time is absolute
That's a consistent approach, but is it correct?
Let's say I'm today in America/New_York and I schedule a local meeting for March 15th at 13:00 (the day after Daylight Savings Time is scheduled to start). The string 2021-03-15T13:00-04:00, or its equivalent epoch time, is saved in your system.
The government then decides to postpone DST by a couple of days.
Your saved epoch time is now equivalent to March 15th at 14:00 in America/New_York. If you display it back to me like that, I'll complain your system corrupted my input.
This can even happen to timestamps in the (recent) past, since abrupt changes can take days to propagate to user's TZ databases and lead to retroactive changes.
If my meeting was stored in your system as "2021-03-15 13:00 [America/New_York]" instead, there would be no problem. The same approach works with the virtual "local" timezone, used for alarm clocks, birthdays, new year celebrations, etc, which cannot be converted to epoch time.
I don't know if this is the best solution, as I've never deployed it at scale. But it sure sounds more logical to me.
Coming from China, western date and time formats puzzle me. In China we use the ISO 8601 order for dates. Because of this, and also for all the reasons stated in the article, I use the ISO 8601 format in all my software. As a user, it really bugs me when an app uses either the European or the US format, but doesn't tell me which one it is.
China's date format isn't as good as ISO 8601. Let's ignore the 3 Chinese characters (年月日) for a moment. The problem is that the Chinese format does not use leading zero padding - e.g. 2021年5月8日 - which makes the format variable-length and much harder to sort.
> If you’re smart enough, you’ve probably also noticed that the American one makes no sense and is just awful
That's simply not true. The American format is designed to reflect how we normally pronounce dates or write them out in long form (eg "September 11th, 2001").
The European format is also flawed. It's similarly divided into three tokens (day, month, year) but they are ordered so that the tokens represent greater magnitudes of time moving from left to right, big-endian-style. The problem is each token is a decimal number which is traditionally written in little-endian-style. So like the American format, you still need special understanding of the format to read dates and they cannot be trivially sorted.
The ISO 8601 format is little-endian all the way through so it is trivially sorted. UNIX time is even easier to sort and compresses much better, but it's rather difficult for humans to read.
No one here is talking about practicality for non-software engineers which is probably 99.9% of the population. It might be fine for sorting and no one gives a shit about endianess. Common person would argue - why do they need to know the year first? Most people encounter dates in the same year, they already know we're in 2021 and it is not as important. Having to laboriously parse YYYY before getting to the most important bits, either month or day depending on what they're trying to do; doesn't seem too practical. I hate writing ISO 8601 dates, even though I know it is logical.
Not everything logical works with humans. In my day to day life (not engineering use), I personally prefer inches and feet, they are just human scale dimensions. Conversion happens less often than you think - most people convey to others that this box is 12x8x8 inches. Conversion from inches to feet happens way less often. I hate fractions though. It would be great if a centimeter was twice as long in physical dimensions. It's just too granular and falls in an uncanny valley. And no one uses decimeter (10 cm) for some reason which is actually nice since it is roughly the size of the index finger.
These "arguments by practicality " are almost always just-so stories.
The Hungarians (and presumably the Chinese) have their own just-so stories about why YMD is the most practical order: you use dates mostly when you sort heating bills, invoices, or even fruit preserves, and in all those cases you need to sort by year first.
Australians will tell you a tale about how "day before month" is human-scale, while "month before day" is not. Heck, ask a German why the decimal comma is superior to the decimal point, and you'll hear plenty of practical-sounding reasons. French carpenters will tell you how they use decimal units because those are much more practical than inches. British people will explain how left-hand traffic is the only practical choice (6a41ef).
People are much better at confabulating reasons for sticking with conventions than they are at telling practical and impractical conventions apart. Indeed, if there was one obviously practical choice, there would be no differing conventions for ISO standards to reconcile.
I believe that these conventions (at least for dates) are indeed the most
practical for their respective languages.
Take for example "October the third, two thousand nine" (10/3/2009, MDY). In German
one would pronounce this as "der dritte Oktober zweitausendneun" (3.10.2009, DMY).
In Hungarian "kétezer-kilenc október harmadika" (2009. 10. 03., YMD). All of these
pronunciations reflect the order numerical dates are written: using any other
convention would simply make them less natural to pronounce.
Now it is certainly not unheard of that the order of pronunciation also changes
(see the British "the third of October"), but changing language is a lot harder
in some cases impossible without breaking grammar than changing written
numerical representations.
Certain orders are grammatically more convenient in certain languages, but that's not the same sense of practical as the one referenced above: cf. "inches are more practical than meters because they have the same spelling in American and British English", vs. "inches are more practical than meters because they're human-scale units".
Sure, date order may be decided based on accidental grammatical features of the target language. But that just reaffirms that "practicality for the common man" is rationalization.
Naturally, the written convention need not affect pronunciation: in the case of numbers, the world standardized on decimals with place values increasing from right to left, but most languages retain their own idiosyncratic ways of naming/reading them This causes negligible friction in practice.
Speaking for the Hungarians: you're right, if you get used to it, you actually don't even notice the leading year if you don't care. The whole thing just seems to be made up. In other words, rationalization of a habit.
Why big endianness is great though, in practice is that most of the time you actually do care about the year when you use the written form AND it's unambigous. The problem with the reverse notations is not that it seems illogical to some people. The problem is that both d/m/y and m/d/y is used and you can't have the faintest idea which one you are looking at.
Now in theory we could have y/d/m, but we fortunately don't, so seeing the first number being a 4 digit one, you know how to interpret the date.
> The Hungarians (and presumably the Chinese) have their own just-so stories about why YMD is the most practical order: you use dates mostly when you sort heating bills, invoices, or even fruit preserves, and in all those cases you need to sort by year first.
I should note that the Hungarians (can't speak for the Chinese) obviously leave out the year when it's clear which year is meant.
30 years ago when most literature was either published recently (newspapers, magazines, etc), or the date of publication was mostly irrelevant (books), your argument makes sense. If you cared at all, what mattered was usually the month and day.
For most of the literature people read in the 21st century, especially this past decade, the year is the most important part. People normally couldn't care less whether something was published 3 days ago or 3 months ago. But knowing whether it was published 3 years ago makes all the difference in the world to its relevancy.
There are many use cases for dates. From publication date to planning vacation on a calendar. What is the most common use for a date? Calendar, I guess? The most frequently used dates we encounter are within +/- weeks from now. In a day to day use, YYYY is useless.
A calendar is a great example because they usually emphasize the month, week, and day graphically, not typographically.
Another common remaining example might be a bank statement. But what's interesting there is that the dates are in a column and the year disappears. It hardly matters whether the year comes first or last because you don't actually notice it at all unless the year is rolling over--conspicuous change in that column.
But when I'm looking at something lacking implicit context regarding publication date, such as an online magazine article, a YouTube video, or a Tweet, the year is the first thing I'm searching for. Even on HN, the rule is that the year needs to be included in the title if it wasn't published in the current year.
I guess for e-mail the day and month are most important (similar to bank statements), unless you're reading really old messages. But I use mutt with a default mailbox view that doesn't even show the year.
By far the most common use I have for dates is filling out forms. In those cases the year is almost always essential.
Speaking from personal experience, even an American can make an effort to use YYYY-MM-DD in any situation asking for a numeric date, and almost always succeed. The biggest exceptions are forms asking for MM/DD, and online payment forms asking for credit card expiration as MM/YY.
> I hate writing ISO 8601 dates, even though I know it is logical.
Nobody forces you to write ISO 8601 dates but if you want your dates to be easily parseable by humans, why would you write them all in numbers?
3 Nov 2020, 3rd November 2020, Nov 3rd 2020, even something like 2020 Nov 3 is uniquely parseable by humans. Even if the human doesn't know the language of the month, they can still find out what date it is from a Google search.
With 3/10/2020 you never know for sure what date it is.
> I personally prefer inches and feet, they are just human scale dimensions.
Meter, centimeters, and millimeters are human scale dimensions, too. Just because you didn't grow up with them doesn't make them non-human.
Not sure, I grew up in two countries, one metric and one english units. I still prefer inches and feet to describe length. I would like decimeter but no one uses it.
Kiwi here, we generally only use pounds for the weight of a newborn, unsure why.
We also tend to still refer to height informally in feet and inches.
That's about our only remaining usage of imperial units apart from inches in penis size. We refer to a serving of beer between 425mL to 468mL as a pint, but it's only a descriptive term and not a legal measure.
Agreed, and needless to say, I use metric system at work (engineering).
Now only if we evolved to have 12 fingers, we would have a supercharged metric system in duodecimal (base 12). Far superior to the decimal number system we use today.
> most people convey to others that this box is 12x8x8 inches
Replace inches with cm, I didn't explain it well. Even if it is centimeter, people would tell dimensions to others more than convert them. The point was about frequency of communication between humans vs. frequency of converting units.
You seem to be taking offense that I said something US-centric. I didn't mean that at all.
I worked on a system once that failed in Sweden when we changed the locale from US.
Someone was getting the date as 01MMMYYYY and using it as a partition name. When the first day of the tenth month happened, everything broke, because it was expecting OCT, not OKT.
Unambiguous but wrong.
With humans reading it, either you need to be unambiguous, so use yyyy-mm-dd, or you don't have to be, so use a format that most of your audience will understand.
> This is a bit more human-readable and closer to commonly-used forms of dates while still being completely unambiguous.
A bit more human readable you say? So 1 фев 2021, 1 Lut 2021, or 2021 فبراير1 are readable to you? I don't know but to me that's just US-centric thinking all over again.
It's not just about years, and it's already explained in the article. When I see the date "02/03" or "02/03/2021", I can't tell if it means "March the 2nd" or "February the 3rd", because websites and software don't consistently detect (or even care) about my locale.
But if the software show 2021-03-02, I unambiguously know which it is.
We weren't so globally connected just 20 years ago, so if you were in US, you were used to MM/DD format and if you were anywhere else, you were used to DD/MM format. It was all local.
Nonsense. People have been commenting on how these two orderings are confusing for far longer than 20 years. Things made in the United States have had worldwide circulation for quite a while, now. Even if one has WWW tunnel vision, Markus Kuhn's WWW page on ISO 8601 has been around since 1995.
If you’re living in Berlin, it didn’t matter what US date format was 20 years ago. You’re missing the point that the globe is far more connected due to the internet.
No, you are missing the point that the globe was connected due to the Internet for far more than 20 years, as evidenced at least by the fact that one of the more widely known treatises on ISO 8601 on the World Wide Web dates from the middle 1990s. And that's merely the World Wide Web, not the worldwide computer networks and communications systems, where dates have been an issue, that pre-date the WWW. The idea that this issue is new because the world only got connected in the 21st century is baloney. Doubly so: The world got connected so that people in other countries saw each other's conventional date formats long before, and people have been discussing date format ambiguities for far more than 20 years.
Bah, humbug. I moved to Canada almost a dodecade ago and despite all person heights and interior design stuff being denominated in imperial units, getting the hang a grasp of any multiples is no more intuitive than in metric units. Metres work similarly well as feet, that is, not great for nontrivial amounts.
Within a certain range you'll do fine either way. Outside of a certain range you'll always need a measuring tape, or you just had a had a lot of practice, eyeballing and learned habits going in.
I think you have a valid point which is irrelevant to ISO 8601 however. You may be right that common dates are in the same year, but such dates would be most conveniently written without the year number at all. If you need to write the year to your date, either because it's not the current year or it's consistent with other dates with the year number, then the year number is significant and all arguments against ISO 8601 breaks down.
I tried to push ISO to my (US/EU) company many times... it just doesnt work because you only need YYYY once in a while. Instead, we've settled on NATO formats (another US+EU org): 3 Nov 21 or just 3 Nov. It's unambiguous and short --yes, harder to parse and sort, but those are computer problems, always easier to solve than human problems...
"3 Nov" is ambiguous, it could mean 2020-11-03 or 2021-11-03, or any other year. And by the way, "3 Nov 21" is also ambiguous, it could be 2021-11-03 or 1921-11-03. Lots of stuff happened in 1921.
Also, "3 Nov 21" works only as long as everyone speaks a language in which "Nov" actually stands for November. Abbreviations can have false friends in some languages. It's the reason most EU personal documents try to avoid using text as much as possible because it's impractical to write it in 20+ languages.
Works fine for the Chinese and Japanese, and last I checked they were humans.
American English already has this weirdness elsewhere - the $-sign in $15 is read in the "wrong" place and always trips me up when I'm reading something out loud but others will defend that practice to the death
No. Every human likely encounters date sorting at some point. And feet and inches aren’t really any more human or natural than 4x5x2 dm or 40x50x20cm. Dividing by 10 isn’t more human either, but adding/removing zeroes or moving a decimal point is certainly easier for the human brain.
Its a pretty clumsy measurement so perhaps not “frequently” but it’s widely used yes (Scandinavia). For example windows and doors are standardized in dm, so a typical window is a 11x13 and a door is 9x21. It’s going to have some other measurement in reality like 1120x1310mm but the dm measurement is still used to reference the rough size.
The US format is indeed awful but so is the European one really. ISO-8601 is the only one that makes sense, although the concept of months isn't really useful at all.
But it's not always unambiguous. ISO-8601 supports local time. It's only an unambiguous timestamp of the time zone is included.
As a european I use ISO 8601 for everything since about 5 years.
One point is also: if you manually write a date, the easiest to remember part (the year) comes first, then the month (which is usually also easily remembered) and then the thing that you can forget at times.
I can beat that slightly. I have things with ISO 8601 dates written on them, by me, dating from 1986. Yes, I started using it before it was formally published as a standard. I initially used the basic format.
I wouldn’t call ddmmyy “European”. Many countries use yymmdd (nordics, for example) which is the iso order. And the order in which alphabetical or numerical sorting works out of the box.
Other than inertia/tradition there is really no excuse for shuffling around a date in any other way.
In Norway, the current standard is dd.mm.yy. Before computers, it was d/m-yy (no leading zeroes). I come across yyyy-mm-dd once in a while, but it is sort of rare.
I got into the habit of writing dates in this way perhaps 20 years ago, in all my writings. People are sometimes surprised at first but the beauty of this is that they immediately get it. It's self-explanatory, obvious, in a way that no other format is.
People look at ISO-8601 and think year-month-day looks great! But don’t realize that it also includes thing like —month-day (yes, you don’t need to include year to have a valid iso date!) year-week, year-day and lots of other things.
So I would generally advise against accepting iso formatted dates and instead decree a single date format.
The unmentioned benefits: it is fixed-width and follows most to least significant parts left-to-right. What this means is that the significance of the parts follows the same L-R convention as numbers, making it intuitively obvious which is the month and which is the day. Oh, and a simple string sort will sort timestamps correctly - very handy at the command line. Even db columns holding timestamps as strings will get the ordering right by default.
"I’m here to (hopefully) change your mind by introducing you to a lesser-known date format called ISO 8601."
It seems so foreign to me, and most people i know, to use anything but ISO8601 or RFC3339. Might be, as with most things, that we here up in the Nordics simply are used to it.
Years before 0 or after 9999 are not defined in 8601 (there is some attempt to allow for them, but it's not really specified). Also, the lexicographic sorting would be ruined (if it isn't already by timezones).
I wish HTTP would ISO 8601 for its dates, or anything sane in any case. Dates in HTTP headers are meant to be machine-readable, right? Then why use month names instead of numbers? Why include the day name? "Wed, 21 Oct 2015 07:28:00 GMT" is just silly. And that's just the preferred format; there are two other formats that are just as idiotic that recipients are supposed to understand.
> In most cases, we want to discern between days first, them months, then years. If you look at a list of dates:
> 2021-01-01
> 2021-01-02
> 2021-01-03
> 2021-01-04
With you so far.
> You're just going to be seeing a heap of noise before you see the actual number you care about.
100% disagree. There's less noise here than having days from other months or years mixed in. If there's noise here then either I am on the wrong page and need to navigate to the correct year or else the data I want has few data points.
> If you consider that days are the most valuable, then months, then years, you get the UK/European format.
> 01/01/2021
> 02/01/2021
> 03/01/2021
> 04/01/2021
Maybe. Your list is contrived. Here's another.
01/01/2021
01/03/2021
01/04/2020
01/10/2021
01/11/2019
02/01/2021
02/13/2019
02/20/2021
Those numbered days are completely irrelevant to each other in most circumstances. Now other months and even other years are mixed in. Expand this list to 1000 data points and good luck figuring out where your data's at.
> In most cases, we want to discern between days first, them months, then years.
That really, really depends on particulars on your life. While I strongly dislike the US format of putting the month first, the irony is, the month is the most important datum for most of the dates I read with. Year is usually obvious given particular context (it's typically either the current one, the next one, or sometimes the previous one). Days don't matter for anything that isn't in the same month. I'd go as far as saying that months are typically the most important for most people in XXI century, then days, then years.
But that's no problem for punctuated date formats in general. People don't read things linearly at letter level, they deconstruct tokens in a random-access way. Separators like - or / help clearly identify which part is which (compare how easy it is to read 03/01/2021 with 03012021), and there's no extra cost associated with reading off the part in the middle.
The benefits of YYYY-MM-DD notation on top of the above are:
- With all terms being fully expanded, dates line up vertically as well, which helps when dealing with stacks of documents or tabular data.
- Being ordered by magnitude like normal numbers provides a Schelling point for interpretation[0]. That is, when a random person who wasn't exposed to much computing or internationalization before sees 2021-01-03, they will automatically assume that 01 must be the month, because writing YYYY-DD-MM would be dumb and inconsistent with how numbers are written in general.
Yes, both of these apply to DD/MM/YYYY, but, YYYY-MM-DD also gets you sane lexicographic sorting, which the UK/European format doesn't. It's super useful feature not just when dealing with computers, but also when perusing any kind of date index. ISO 8601 dates work much like words in a dictionary, you can binary-search through them.
Generally speaking, a lot of these issues are knowing when it's appropriate to use what format. When displaying a date to a user, you do it in their configured local time, and in their configured date/time format. I don't think the author is advocating changing that behavior[1].
Where the problem comes in is "how you store date/time values". Normally, I don't find myself arguing as to the format. Generally speaking, people default to ISO-8601 for log file naming (many probably not realizing that's what they're doing -- aiming only for a naturally sortable list). The places I tend to store dates (databases) define how they're stored, otherwise. That doesn't mean a developer isn't going to store the date in server local/user local time (and often make discovering the reference time zone impossible). Please don't do this. Store in UTC.
I'm not sure why the author is so hung up about the ordering of the dates, but while I worked in telecom, I briefly had a boss that was really particular about that (I've worked for a few folks in the UK, only this first boss had hang-ups). The US ordering probably originates from the most common way dates are spoken in the US: "Januaray 17th". A year is less frequently necessary, but when it is, it's tacked on the end. I don't think anyone thinks the way we write dates is particular superior, it's just the way we've done it since we first learned about dates.
One thing I learned when I started working regularly with non-US folks. Never use numerical dates. Even if you write it in the format they are comfortable with, if there's any ambiguity, they're likely to assume you wrote it in the US format. I started writing/abbreviating month names. I ended up altering the written order, as well "17th of January or 17 Jan" because that particular first boss jokingly-non-joked about how obnoxious the other way was.
Everybody's got their tabs/spaces war, I guess!
[0] OK, so it's more of a pet peeve.
[1] While it would be nice if we all used the same date/time format in our day-to-day life, it's one of those things that I'll wager will never happen... and I'd argue that doing so would cause more problems than it would help.
> Maybe the European date format is better because the elements are in the order of relevance?
> ... when we’re talking about events occuring on a day-to-day basis, however I can think of numerous cases when the year and the month are more relevant
I think that's the "sense" of the American one. It optimizes "metal sort" for month.
This article is primarily about the date format, and that doesn't have anything to do with the timezone, so it's a bit unfair to hold time zone issues against it. Some issues are also self-made because people (including people who write libraries, frameworks etc.) choose to store a date (e.g. somebody's birthday) as a datetime...
Date and time are separated by "T" and timezone is specifiable but optional.
From wikipedia:
"If a time zone designator is required, it follows the combined date and time. For example, "2007-04-05T14:30Z" or "2007-04-05T12:30−02:00"."
ISO-8601 was a good early attempt, but unfortunately it has some negative points:
- Only offset-based time zones are allowed (which are next to useless).
- Omitting the time zone defaults to local time, which renders the time ambiguous. Defaulting to UTC makes much more sense.
- BC dates are all offset by 1 ("-1" = 2 BC). I know the reasons for this, but this could have been moved to the implementation and not exposed to the user.
- Lots of silly things like fractional-minutes and multiple ways to represent the same data bloat the spec and implementations.
Quite nifty and clean; I think this could play well with support for the duration (P-Y-M-D...) format in ISO 8601 that declares a positive offset. https://en.wikipedia.org/wiki/ISO_8601#Durations
Interesting, didn't know about that! Do you know of some canonical way of expressing negative offsets in spirit of ISO 8601? I don't seem to see those mentioned in the article...
Unfortunately not, for the project I'm working on right now I only needed 'forward' durations. There's a W3C extension that proposes a preceding - sign for negative durations, which I think it's fair https://www.w3.org/TR/xmlschema-2/#duration. The ISO standard explicitly declares durations to be non-negative, on the other hand.
It's not tedious if you do it right. All of your conversions should be done in your I/O layer and nowhere else. For many applications that means there's a single place to do it. Hardly tedious.
I notice that your library is targeted at notebooks, though. It seems useful in that context, but not for general programming.
Having mm/dd/yyyy and dd.mm.yyyy wouln't even be so bad if people did not also write mm.dd.yyyy and dd/mm/yyyy and mm-dd-yyyy and dd-mm-yyyy and mm.dd.yy and dd/mm/yy and mm-dd-yy and dd-mm-yy and mm.dd and dd.mm and mm/dd and dd/mm.
I've been caught out by doing date comparisons in Spark SQL using string yyyy-mm-dd against string yyyy-mm-dd 00:00:00. It's easy to think that the trailing 00:00:00 will have no impact on date comparisons but it does! Lesson learnt: use substr(date, 1,10)
I have recently been inviting my American colleagues to meetings using times-as-American-dates format. In other words, proposing meetings to be on 02/26/21 at 25:23
(This example meaning February 26th 2021 at 25 minutes past 23 hours).
is he being ironic? One of the things I love most about 8601 is it being supported by basically every* std lib (and definitely every library working with dates)
Most humans talk about (month, date) tuples. US dates are big endian and written mm/dd. 12/25, 10/1, 2/28. They are elegant and compact and visually sort in the correct way eleven times out of twelve (11/12.)
Short UK dates are spoken as “Jan 9th” “8th of March” and written as such, or sometimes “Feb 9”. I find them very less pleasing.
Longer UK dates in Guardian format are prettier: 3 Jan 2022.
US dates inevitably have to be unambiguous about years. This is indeed unwieldy because a slashed triple — 3/4/22 — is used in the UK too. (The slashed pair is uncommon so it’s clear that 3/4 is an American date.)
Anything technical should indeed use ISO, but if you have an audience in a single locale it’s important to know your audience and localize (localise) accordingly.
I prepend my filenames with soemthing like `YYYY-MM-DD_HH:MM:SS.sss` or if second is enough `YYYY-MM-DD_HH:MM:SS`. The `T` there makes it hard to read for humans imho.
my birthday is at the end of the month, during a processing of a document for my US visa 10+ years ago, I was dealing with 2 different sites, one accomodating my local date formatting, and one fixed for the US standard. I was puzzled that I had been made 2 years younger when verifying my data, turned out my birth date of month was now month number 24+ of the year, pushing my birth ahead, and my birtb month had become my birth date of month.
A note from the front line. I actually use 8601 dates in a date-heavy consumer product ( https://clubman.app ) and it’s hands down the feature I most consistently get user feedback on.
It’s always “Why are the dates all American format? Can you change them to English?” And then I try to patiently explain that they’re actually international format.
People seem to have internalised that any date format they find slightly unfamiliar is “the bad American one”
I’m in the process of cutting everything I can over to “24th Jan 2020” style.
Another advantage to outputting 8601 dates is it's easy to mechanically parse - you can probably find some JS to rewrite the 8601 dates coming from the server into whatever the user's current locale is. Bonus points: if your timestamps are UTC, the frontend reformatting can even take timezones into account (such that an American and an Australian could correctly see different dates for the same timestamp).
I did try rewriting dates into a user's locale as specified by the browser. The trouble there is that a lot of people seem to have that set to en-US rather than en-AU. So I still got a bunch of people unhappy that the dates were American!
is also right and allowed in ISO 8601. Especially useful when you add time. You don't e.g. want character ":" in your file name 20210226T205418 (local time here)
Note that common usage and the official definition may well differ. Most Americans probably consider Monday the "first day of the week" as it is the first day in a standard work week. But officially, Sunday is the first day of the week.
No, the 7th day from Genesis is Saturday, and Saturday was the proper day for the Sabbath before Jesus. Sunday became the holy day of rest in recognition of Jesus's resurrection on Easter. That's at least the standard Christian interpretation that I've heard.
I've read some historians state that Christians started using Sunday as their Sabbath day in order to distinguish themselves more sharply from the Jews.
There are some Christian denominations which use Saturday as their Sabbath day, such as Seventh-day Adventist Church, so using Saturday as the holy day is a minority practice among Christians but it's a significant minority.
historically europe also started the week on sunday as per christian tradition. i too grew up with the idea that the week starts on sunday.
this change to starting the week on monday is therefore a recent development.
same in china btw. days in china are numbered. monday is number 1, and sunday is 7. so while people may have the idea that the week starts on sunday (i don't know) the day numbering suggests that it actually starts on monday.
same goes for europe. monday by law and sunday by tradition
My understanding is that all days except Sunday "week-day" (星期日) are numbered. Monday is (星期一) "week-one". So there is still some room for ambiguity left if you allow for counting from 0.
A day corresponds to an actual rotation of the Earth, i.e., a day-night cycle.
A year corresponds to an actual revolution of the Earth about the Sun, i.e., seasons.
A week corresponds to...nothing. Four of them are a (very) rough estimate of the phases of the moon, but that's not something that really matters to anyone other than sailors nowadays.
Well, the Bible says that you shall rest on the seventh day of the week, which in certain religions is known as Sabbath or Shabbat or whatever, which as we all know maps to Saturday. Without having really done the research, I've been ascribing the US calendar idiosyncrasy to religious influences... and really, that's what Europe does as well, they just picked a different mapping.
So now when we rest, both the Jews and the Christians get their favorite day off and yay, we have a two-day weekend.
What practical difference does it make to you? The week starts whenever you decide it starts. Would it annoy you even more if I decided to start my week on Thursday?
It makes sense to me that the weekend comes at the end of the week, but then again, I don't know what came first, the term "weekend" or the convention of Sunday being the start of the week in some countries
I think it's just one of those things that doesn't really make sense to anyone, but one way makes slightly more sense to some than others.
In reality there is no week end. The only periods that exist are days and years (and lunar cycles). Weeks are artificially constructed and it can begin and end whenever we want. I can see the sense in saying the week ends at the end of Sunday so the weekend is the bit before that. I can also see the sense in saying the week ends at the end of Saturday and the weekend is around that.
Starting weeks on Sundays has the ill effect of centering every calendar page on the work week, with the work-free days relegated - nay, shoved out - to the margins. The cynic in me says this is by design. Perhaps a capitalist plot to denigrate time away from work? It would be psychologically satisfying to have every calendar week begin on a Monday so that every work week ends with a prominent, uninterrupted two-day block of work-free time.
