ISO 8601: a better date format(kirby.kevinson.org)
kirby.kevinson.org
ISO 8601: a better date format
https://kirby.kevinson.org/blog/iso-8601-the-better-date-format/
434 comments
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.
FTA:
“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.”
“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).
Only true if you ignore timezones and DST (which most people do because it is unholy mess) or stick to UTC.
You don't need to stick to UTC, you just need to stick to a single timezone. Which is something that is generally true.
UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard.
UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard.
> 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.
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.)
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.)
or until you get into 5 digit years
NMP. :D
It can be a problem/nuisance if you're working with nuclear waste or orbits.
It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed.
It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed.
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.
Lexicographic sorting does not work for numbers of different lengths, e.g. "100" and "9".
It does if you zero fill the shorter number to an equal number of digits: "100", "009".
There's a special place in hell for people that using variable length representations for time units that are meant to be consumed by machines.
I think it's across the hall from the room for people who configure servers for anything besides UTC.
I think it's across the hall from the room for people who configure servers for anything besides UTC.
Where do you put the people who think that we should inflict leap seconds on UTC?
UTC has leap seconds by definition. Conventional POSIXish epoch time is a little more complicated – typically, the length of a second varies.
I am fully aware.
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?
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.
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.
for accuracy
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.
Meanwhile leap seconds decrease accuracy when measuring long time periods unless you explicityly remove them again.
In a special room resting atop a centrifuge so they can spend eternity arguing with each other about how long they've been in there.
Is their punishment to be forced to parse "009" with the C language's strtoul() library function for all eternity? (-:
What's the problem with strtoul? Just make sure to pass 10 as the third parameter, not 0.
Error handling is pretty horrible. And also it happily accepts negative values.
Maybe the punishment in hell should be to RTFM for the rest of eternity.
Sorry, what?
It's not like it's a default parameter, you would have to explicitly pass zero if you want the "guess base based on prefix" behavior.
It's not like it's a default parameter, you would have to explicitly pass zero if you want the "guess base based on prefix" behavior.
Even though it mentions this in the context of filenames being sortable, I agree that this should have been a bullet point of its own.
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
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.
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
Would be interested where anyone encountered issues with ISO8601 dates
> H never follows C in Slovak or Czech language
"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-".
"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-".
"your filesystem will automatically sort files correctly if you prefix them with a iso 8601 date."
It's the default date format on my PCs, I've used it for decades. I find it hard to understand why eveyone doesn't use it.
Also, if you work for the UN, it's the default date format.
It's the default date format on my PCs, I've used it for decades. I find it hard to understand why eveyone doesn't use it.
Also, if you work for the UN, it's the default date format.
Also every language has a tag for that format (.toISOString()), where as the other formats might require entering your own printf spell
Most forms are sortable, though dates with a timezone specified are not sortable.
That’s why I use it exclusively to prefix my file names. It’s sortable, easy to parse visually and always has the same length.
Except on Android, since you may not have files with the ":" characters in it.
[deleted]
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.
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.
Americans using cal/foot/elbow/galon system of measurements is quirky, but bearable.
AM/PM thing is silly, but bearable.
Malformed MM[/-.]dd[/-.]yyyy date format is one of the most confusing thing I have ever encountered and it generates serious problems.
AM/PM thing is silly, but bearable.
Malformed MM[/-.]dd[/-.]yyyy date format is one of the most confusing thing I have ever encountered and it generates serious problems.
> it generates serious problems
I would say that by just existing it create serious problems. You can never be sure if a date if day/month or month/day, this was especially bad from year 01 to 12. During those twelve years I was a date zealot "there can be only ISO 8601".
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...
> it generates serious problems
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.
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.
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.
Sane Linux Locale settings
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.
Sane Linux Locale settings
LANG="en_US.UTF-8"
LANGUAGE="en_US"
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_DK.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
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.
This is one of my biggest gripes with GNOME, along with the incredibly stupid lack of thumbnails in the file browser.
And the way if forces you into a full-blown file search when you start typing letters and are just looking for files with that prefix...
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.
That still hasn't been fixed? It's been so long it's become an old meme at this point. People still mock Linux for it...
Probably those are from the locales package?
en-dk is the best one, it is Europe standard english which I think fits all your requirements for Saneland.
en-dk is the best one, it is Europe standard english which I think fits all your requirements for Saneland.
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.
An artificial en-xi or similar is probably best: take en-ie, and just change the short date format.
en-dk has ISO 8601 though you're right it uses the comma.
https://github.com/lattera/glibc/blob/master/localedata/loca...
https://github.com/lattera/glibc/blob/master/localedata/loca...
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).
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.
Right, en_DK has almost nothing to do with Denmark, instead it's basically the imaginary Saneland the top poster asked for.
I agree en_EU would make more sense, maybe somebody should submit a patch to glibc and in a decade it'll be safe to switch.
I agree en_EU would make more sense, maybe somebody should submit a patch to glibc and in a decade it'll be safe to switch.
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".
But there should definitely be a saneland locale. "en_SANE.UTF-8".
Can we petition the government of Null Island (Lat 0, Long 0) to adopt the SaneLand defaults?
Salesforce does the same thing so I tell it I’m Latvia. It kinda works until it doesn’t.
The country should be called Esperantonia
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.
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.
> I've never actually read the ISO 8601 spec, like probably most people here
Indeed. The comprehensive Wikipedia article on ISO8601 is as far as we go
https://en.wikipedia.org/wiki/ISO_8601
Thanks for pointing out rfc3339 - this appears to be the "useful part" of ISO8601 for data interchange.
https://tools.ietf.org/html/rfc3339
Indeed. The comprehensive Wikipedia article on ISO8601 is as far as we go
https://en.wikipedia.org/wiki/ISO_8601
Thanks for pointing out rfc3339 - this appears to be the "useful part" of ISO8601 for data interchange.
https://tools.ietf.org/html/rfc3339
Draft versions of the ISO standard are easy enough to find on the internet. But the Wikipedia article is excellent and covers just about everything.
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.
[1]https://www.loc.gov/standards/datetime/
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.
[1]https://www.loc.gov/standards/datetime/
Every time there's a discussion on date/time formatting I always refer people to RFC 3339 (https://www.ietf.org/rfc/rfc3339.txt).
Learn it, live it, love it!
Learn it, live it, love it!
> 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.
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 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.
IEEE publishes several standards for free via their IEEE Get Program
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.
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.
[deleted]
> 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?
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.
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.
Free versions of the actual specs:
https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i...
Or https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en
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.
[1] https://en.wikipedia.org/wiki/ISO_week_date
https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i...
Or https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en
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.
[1] https://en.wikipedia.org/wiki/ISO_week_date
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.
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.
What about the Durations and Intervals?
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.
They're just as unambigious and just as useful.
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.
They're just as unambigious and just as useful.
Week numbering introduces confusion when interacting with countries like the U.S. where weeks aren't considered to start on Mondays.
Yeah I am a fan of ISO-8601 durations.
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.
i don't think mentioning it in the context of specifically excluding it is going to cause any confusion though.
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.
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.
/rant over
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.
/rant over
> 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"
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.
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’m down for the years to be counted from the storming of the Bastille, personally...
Point them at the fiasco where NASA mixed up Imperia and Metric.
And also ask but why are we not targeting international customers.
And also ask but why are we not targeting international customers.
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.
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.
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.
Yes! I constantly get complaints when using ISO 8601 on school documents. But I won't stop using it.
I guess the complaints are because the format is unfamiliar and strikes non-software people as being non-standard.
Perhaps use a format like 3/Nov/2021?
Perhaps use a format like 3/Nov/2021?
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.
Maybe it's just Croatian that's ruining it for everyone.
I'm guessing every language ruins something for everyone else.
Around this part of the world, almost everyone calls tea by some variation of the word "chai". But not us. In Polish, it's herbata!
Around this part of the world, almost everyone calls tea by some variation of the word "chai". But not us. In Polish, it's herbata!
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).)
(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.)
(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.)
No.
People were unfamiliar with showering and brushing their teeth. We move forward.
People were unfamiliar with showering and brushing their teeth. We move forward.
> ISO 8601 everything. [...] on government forms
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).
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.
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.
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.
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.
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.
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?
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.
3/11/2021
3/11/2021
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.
31/11/2021 is quite ambiguous, I can’t find such a date on my calendar, by either notation.
I’ve scheduled cron jobs for February 31st, to have them tracked but disabled.
I’ve scheduled cron jobs for February 31st, to have them tracked but disabled.
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.
the point is, no program writes the date YYYY-DD-MM (or at least, it's very rare).
users who don't know what ISO 8601 is would learn, simply because when that format is used in software, it is consistent!
users who don't know what ISO 8601 is would learn, simply because when that format is used in software, it is consistent!
> YYYY-DD-MM (or at least, it's very rare)
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).
[0] https://en.wikipedia.org/wiki/Date_format_by_country
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).
[0] https://en.wikipedia.org/wiki/Date_format_by_country
> Date().toLocaleDateString()
> Uncaught TypeError: Date().toLocaleDateString is not a function
That doesn't seem like a standard API call.
That doesn't seem like a standard API call.
It is standardised and widely implemented.
https://developer.mozilla.org/docs/Web/JavaScript/Reference/...
Your code has a bug, missing constructor.
https://developer.mozilla.org/docs/Web/JavaScript/Reference/...
Your code has a bug, missing constructor.
Looks like an instance method, rather than a static.
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 ⌘?
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 ⌘?
Stuff like this is the reason why I, as a non-american software engineer, use `US_en` layouts on all my machines.
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.
[0]: https://eurkey.steffen.bruentjen.eu/
[0]: https://eurkey.steffen.bruentjen.eu/
I use a Japanese keyboard that pretends to be a US-ANSI on my laptop. The extra keys and narrow spacebar are super handy.
Something like http://www.keyboard-layout-editor.com/#/gists/9150730dbd4d28...
Something like http://www.keyboard-layout-editor.com/#/gists/9150730dbd4d28...
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.
Same. When I have to use someone else's computer without an US_en keyboard I look like an elder learning to type.
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.
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).
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).
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.
Until people get used to emoji...
And not supporting UTF-8 is suddenly a big problem even for English people now.
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.
It’s really well done - and usually Identifies the most common keyboards in only a few key presses.
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.)
And multiple languages. Spell-chackers enabled by default are specially annoying.
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.
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.
Use https://en.wikipedia.org/wiki/Tz_database names instead.
Use https://en.wikipedia.org/wiki/Tz_database names instead.
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`
I have taken to writing 11 March 2021 or similar whenever possible. But sure, 2021-03-11 is also fine, when trying to save something machine readable.
The US conventions are indeed horrendous.
The US conventions are indeed horrendous.
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.
Another great thing about 2021-03-11 is that it ascii sorts correctly.
This is the big one when it comes to sorting files and directories on disk. It makes sorting and finding what you look for so much easier.
Non-scientifically, about 20% of people won't: https://twitter.com/troyhunt/status/978747364105011202
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.
I have seen non-Americans write YYYY/DD/MM before. Hyphens are key here.
That is horrifying.
I am glad I have never met these people.
I am glad I have never met these people.
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".
eye_twitch.gif
> 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.
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.
I also always write 11 मार्च 2021 or similar whenever possible. No problems so far.
I go with 「２０２１年０３月１１日」. Free bonus test included for whether software handles alternate numerals ;)
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.
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?
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?
金 from 金曜日 (Kinyōbi) means Friday. The letter correspond to the planet the weekday was named after, just like in English (金星 is Venus)
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].
[1] https://en.wikipedia.org/wiki/Interpretatio_germanica [2] https://en.wikipedia.org/wiki/Lokasenna
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].
[1] https://en.wikipedia.org/wiki/Interpretatio_germanica [2] https://en.wikipedia.org/wiki/Lokasenna
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
"金" 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
Absolutely agree. Also in some cases you get "tables" aligned for free (... if there's nothing else length-varying.)
Sure you can tell. You just hire an investigator to find out who wrote the memo, and find where in the world they grew up, in what culture.
If the answer comes back very US, then it's middle endian US format. Else it's DMY.
Note that the article is wrong to just say "dd.mm.yy" is used in "Europe". Some countries use yyyy-mm-dd and others dd/mm/yy.
The US format is the only one that's retarded, though.
If the answer comes back very US, then it's middle endian US format. Else it's DMY.
Note that the article is wrong to just say "dd.mm.yy" is used in "Europe". Some countries use yyyy-mm-dd and others dd/mm/yy.
The US format is the only one that's retarded, though.
Canada is even worse, we can't decide which one to use so you never know what format it's in.
I was once sent paperwork to fill out that had dates requested in both MM/DD/YYYY and DD/MM/YYYY formats on different pages.
I was once sent paperwork to fill out that had dates requested in both MM/DD/YYYY and DD/MM/YYYY formats on different pages.
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.
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.
> The US format is the only one that's retarded, though.
I wonder how it started? A skim of the internets hasn’t enlightened me.
I wonder how it started? A skim of the internets hasn’t enlightened me.
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.
But people are very good at verbally saying different than is written.
No native speaker but isn't 4th of July more common than July 4th?
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.
The Fourth of July and Cinco de Mayo are exceptional days.
Tax day is the ides of April, but we just say April 15th.
Tax day is the ides of April, but we just say April 15th.
Somehow the rest of the anglosphere doesn't use that format.
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 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.
This reminds me about Americentrism: https://jlelse.blog/thoughts/2021/02/americentrism
America first!
America first!
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.
but then you get an email from an American living in Paris and it's 11/3/2021 with dashes and God knows what he meant.
M/D/Y is a bit like the German way of reading numbers. 328 become three hundred, eight and twenty. Terrible
How about french? 99 is four twenties nineteen, 79 is sixty nineteen. Languages are fun and fascinating.
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
- 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.
You may not be able to correct it from the Information available but you’ll know something went wrong.
Still better then russians: ten, twenty, thirty, bag of furs, fifty, sixty, ...
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.
Nope, just French.
Nope, just French.
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.
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:
https://xkcd.com/1179/
It is one of my favourites (the "8601", the "Security", and the "Bobby Tables")
https://xkcd.com/1179/
It is one of my favourites (the "8601", the "Security", and the "Bobby Tables")
You can change the display format, but I really wish M/D/Y wasn't the default - it's just too ambiguous.
This is mentioned in the article....
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.
You're saying that 06-03-2021 is shorthand for 2021-06-03 and are confused why people don't get that?
> 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.
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.
It is American. In the UK, we'd write 11th March 2021. But I don't mind too much when it's non-ambiguous like this.
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”.
Yes.
The 27th, or the 27th of February.
To us, US English seems to skip a lot of the small joining words of various flavours.
To us, US English seems to skip a lot of the small joining words of various flavours.
ISO 8601 contains durations and time intervals which are totally undervalued! (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals)
E.g.: 2021-05-01T12:00:00Z/P2H
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.
For JVM developers, there is a library out there that has amazing support: https://github.com/MenoData/Time4J
For python developers, there is pendulum which supports most of the functionality.
E.g.: 2021-05-01T12:00:00Z/P2H
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.
For JVM developers, there is a library out there that has amazing support: https://github.com/MenoData/Time4J
For python developers, there is pendulum which supports most of the functionality.
100% agree that it's undervalued.
Was just in a software design meeting where they were trying to figure out how to represent exactly this: a time interval.
I had to repeat "Just read ISO 8601 and use it" like a dozen times.
"Bu-bu-but what if we want to represent a recurring..."
READ IT. AND USE IT.
Was just in a software design meeting where they were trying to figure out how to represent exactly this: a time interval.
I had to repeat "Just read ISO 8601 and use it" like a dozen times.
"Bu-bu-but what if we want to represent a recurring..."
READ IT. AND USE IT.
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.
As of Java 8, the JDK also has support for ISO duration formats, via java.time.Period and java.time.Duration.
Shouldn't it be /PT2H instead of /P2H?
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.
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.
Markus Kuhn has been making this point since 1995.
* https://www.cl.cam.ac.uk/~mgk25/iso-time.html
* https://www.cl.cam.ac.uk/~mgk25/iso-time.html
It's also neat how the character for month and day are the same as characters for moon and sun respectively.
I suppose that means we could also do the following if we really wanted a western version:
2021⊕317
Edit: Turns out that hackernews isn't quite astrological unicode compliant yet but imagine the astrological symbols for sun and moon in there as well.
I suppose that means we could also do the following if we really wanted a western version:
2021⊕317
Edit: Turns out that hackernews isn't quite astrological unicode compliant yet but imagine the astrological symbols for sun and moon in there as well.
Sounds like the convention used in some countries for time, using e.g. 9h20 instead of 9:20
Maybe we should also start speaking Chinese since it may not be a bad idea to use something a large number of people will easily understand.
Edit: this is not sarcasm. It’s simple logic, unless there is something wrong with learning other languages.
Edit: this is not sarcasm. It’s simple logic, unless there is something wrong with learning other languages.
Sigh... I never remember the names of the logical fallacies, I have to look up them, thanks a lot.
Anyways, here's yours: Slippery Slope.
Anyways, here's yours: Slippery Slope.
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.
FYI: English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers. https://www.visualcapitalist.com/100-most-spoken-languages/
FYI: English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers. https://www.visualcapitalist.com/100-most-spoken-languages/
> More people natively speak Chinese than any other language in the world
You've made the assumption that all Chinese people speak one language, which is a false assumption I'm afraid [1].
[1] https://en.wikipedia.org/wiki/Languages_of_China
You've made the assumption that all Chinese people speak one language, which is a false assumption I'm afraid [1].
[1] https://en.wikipedia.org/wiki/Languages_of_China
> You've made the assumption that all Chinese people speak one language,
No I didn’t. I cited the fact that Chinese is the largest natively spoken language in the world, by an order of magnitude.
No I didn’t. I cited the fact that Chinese is the largest natively spoken language in the world, by an order of magnitude.
All of them can read the characters for year/month/day though.
[deleted]
https://www.statista.com/statistics/266808/the-most-spoken-l...
Unless it's already out of date...
Unless it's already out of date...
>English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers
Why would that matter? Arguably the ideal lingua franca should have no native speakers at all as those have an unfair advantage.
Why would that matter? Arguably the ideal lingua franca should have no native speakers at all as those have an unfair advantage.
> 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.
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.
[deleted]
Your numbers above list 1.132B English speakers and 1.116B Mandarin 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.
> Where’s the logical fallacy?
This is terrific, thank you. So meta.
Other popular examples:
"Is this some kind or radical new therapy?" from What About Bob? https://youtu.be/0pKymngWgJw?t=50
McNaulty from The Wire https://www.youtube.com/watch?v=sIvsTXnik7Q
This is terrific, thank you. So meta.
Other popular examples:
"Is this some kind or radical new therapy?" from What About Bob? https://youtu.be/0pKymngWgJw?t=50
McNaulty from The Wire https://www.youtube.com/watch?v=sIvsTXnik7Q
I think we should. At the very least, our children should.
That's why I'm planning on having my daughter learn Mandarin along with English - to prepare her for the shape of the economy she'll be living in.
That's why I'm planning on having my daughter learn Mandarin along with English - to prepare her for the shape of the economy she'll be living in.
I’m doing the same with my kids. Cheers.
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.
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.
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.
as more people learn chinese, the available labor pool grows and these jobs may well require chinese skills in the future
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.
Lots of people learn English because a large number of people speak it. Why should it not apply to Chinese or other often-used languages?
Thats exactly the point I’m making in my post. Glad you agree
All right. Seeing your downvotes, I thought you were being sarcastic.
Being able to speak popular languages is in fact often advantageous for the multi-linguist.
Very good and very true point. Multi-linguism only has upsides.
The "downside" is the time you need to invest to become proficient, which you could have spent on something else.
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.
Is her middle name \";DROP TABLE users;?
this is responsible and good parenting! thumbs up
[deleted]
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.
It's there:
> This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename.
My issue is with:
> Simplified, the core date format looks like this: yyyy-mm-dd hh:mm:ss
Here are the examples at https://en.wikipedia.org/wiki/ISO_8601
Note the optional use of "-" and ":"? That's "basic" vs. "extended" formats.
Plus the optional timezone specifier (if not present, assume it's the same timezone).
There's also optional support for microseconds.
> This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename.
My issue is with:
> Simplified, the core date format looks like this: yyyy-mm-dd hh:mm:ss
Here are the examples at https://en.wikipedia.org/wiki/ISO_8601
2021-02-26T06:22:59+00:00
2021-02-26T06:22:59Z
20210226T062259Z
Note the optional use of "-" and ":"? That's "basic" vs. "extended" formats.
Plus the optional timezone specifier (if not present, assume it's the same timezone).
There's also optional support for microseconds.
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.
[1]: https://en.wikipedia.org/wiki/Date_format_by_country
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.
[1]: https://en.wikipedia.org/wiki/Date_format_by_country
> (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.
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.
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.
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.
In other words, you are not using a standard format.
I think of it as a modified form of the standard format, where the standard format doesn't fulfill the needs of my use case.
I omitted this detail on purpose to not distract the reader who doesn't know much about date formats.
How would you describe the accuracy and veracity of
> "Here there’s only one correct way to write a date,"
given that there are multiple correct ways, and the way shown wasn't actually ISO 8601 but RFC 3339?
> "Here there’s only one correct way to write a date,"
given that there are multiple correct ways, and the way shown wasn't actually ISO 8601 but RFC 3339?
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".
No need for an illusion when synecdoche works.
ISO 8601 is a complex specification because of the many different ways to describe times, dates and duration. Don't let that complexity throw you off! The ISO 8601 timestamp format is clean and elegant. These examples will use the widely used ISO 8601 profile known as RFC 3339, which I'll refer to simply as "ISO 8601".
No need for an illusion when synecdoche works.
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.
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".
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".
My great great grandfather wrote a book about this 120 years ago! And yes, it was for taxes and accounting.
[deleted]
Until we hit year 10000, but yeah, that's still a looong time to go.
There's some proposal that this year 2021 is actually 12021, to make the year neutral of some specific religious event.
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)
(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”.
https://en.wikipedia.org/wiki/Holocene_calendar
https://en.wikipedia.org/wiki/Holocene_calendar
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.
[0] https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesu...
So now we have: another calendar, that has a starting year that is defined by subtracting an arbitrary number from a compromise between alledged years some person was born in.
I love how humanity has the capability to invent new things with increasing complexity.
[0] https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesu...
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.
I wish it was the norm.
I wish it was the norm.
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.
This has been my experience as well.
Sometimes I tell onlookers that it's an ISO standard.
Sometimes I tell onlookers that it's an ISO standard.
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]"?
[0]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
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]"?
[0]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
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.
[1]: http://cr.yp.to/libtai/tai64.html
[2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time
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.
[1]: http://cr.yp.to/libtai/tai64.html
[2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time
I knew about TAI but TAI64 is new to me, thanks.
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.
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).
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).
Most of the time you’d just need their current timezone offset (not location) to convert the stored offset into, no?
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.
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).
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.
[0]: https://www.bbc.com/news/world-asia-16351377
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.
[0]: https://www.bbc.com/news/world-asia-16351377
> 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.”
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.”
OK I'm game... maybe I'll learn something
> - 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?
> - 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.
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.
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.
> The American format is designed to reflect how we normally pronounce dates or write them out in long form (eg "September 11th, 2001").
In the UK at least, we don't write or say dates in that order. With the exception of September 11th.
I believe it's the same in German, 4te Juni etc.
In the UK at least, we don't write or say dates in that order. With the exception of September 11th.
I believe it's the same in German, 4te Juni etc.
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.
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.
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.
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.
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.
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.
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.
This way we can never reach consensus and beat about the bush! Welcome to the bike shed. What color should we paint it with?
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.
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.
I think I need to labor on my point a bit more.
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.
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.
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.
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.
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.
This came up in a r/AskEurope thread and at least some slavic countries use decimeters.
But that's the beauty about easily convertable units. Even if other people use other conventions, the mental process to convert them is almost zero.
Just imagine somebody giving their height just in inches instead of the usual feet and inches?
Could you mentally parse what 76 inches are?
I guess you have basically no problem with 193cm, 1.93m , or "one ninety-three", or even 19.3dm.
But that's the beauty about easily convertable units. Even if other people use other conventions, the mental process to convert them is almost zero.
Just imagine somebody giving their height just in inches instead of the usual feet and inches?
Could you mentally parse what 76 inches are?
I guess you have basically no problem with 193cm, 1.93m , or "one ninety-three", or even 19.3dm.
English/Australian people used to (still do?) measure their weight in stones and pounds. The average man was "13 stone" which is 182 pounds.
US people measure their weight in pounds, 182lb
So yes, a USian telling their weight to a UKian would be like saying their height in inches.
US people measure their weight in pounds, 182lb
So yes, a USian telling their weight to a UKian would be like saying their height in inches.
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.
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.
https://en.m.wikipedia.org/wiki/Duodecimal
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.
https://en.m.wikipedia.org/wiki/Duodecimal
Well, one of the oldest known systems was already very good. Alas, the Babylonian numeral system didn't completely make it down to us unfortunately.
> laboriously parse YYYY
Really? It's hard to parse the year??
What about when you come across a piece of paper written some time ago, is it not useful to know the year?
> most people convey to others that this box is 12x8x8 inches
"Most people" == nobody outside of the US.
> And no one uses decimeter (10 cm) for some reason which is actually nice since its the size of the index finger
I just measured my index finger. It is 8.45 cm.
Really? It's hard to parse the year??
What about when you come across a piece of paper written some time ago, is it not useful to know the year?
> most people convey to others that this box is 12x8x8 inches
"Most people" == nobody outside of the US.
> And no one uses decimeter (10 cm) for some reason which is actually nice since its the size of the index finger
I just measured my index finger. It is 8.45 cm.
> 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.
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.
> Really? It's hard to parse the year??
Is it so hard to write "it is?" Nevertheless, you used a contraction.
You did so entirely unconsciously because that's how langauge works.
Is it so hard to write "it is?" Nevertheless, you used a contraction.
You did so entirely unconsciously because that's how langauge works.
Meters are "human scale". To say not is nonsense.
And 3/2. Is that the future or the past? No way to know. Did you miss the meeting, or is it next week?
"No one uses a decimeter"... What bubble do you live in? But please, lecture some more about cultures you don't understand.
And 3/2. Is that the future or the past? No way to know. Did you miss the meeting, or is it next week?
"No one uses a decimeter"... What bubble do you live in? But please, lecture some more about cultures you don't understand.
I’ve never read anywhere on any product dimensions written in decimeter. Show me one and prove your point.
Show me a tv measured in cups.
The alternate I like to use on forms and such when I know it's likely going to be read by a human is "DD Mon YYYY", e.g.
1 Feb 2021
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.
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.
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.
>2021 فبراير1
I was going to ragequit at you for copy+pasting something into google translate, as it's شُبَاط not فبراير.
but TIL, only in the Levant do we say شُبَاط apparently.
I was going to ragequit at you for copy+pasting something into google translate, as it's شُبَاط not فبراير.
but TIL, only in the Levant do we say شُبَاط apparently.
That's true, but as I said, I just use this in certain human-read contexts, e.g. paper forms. Which in my part of the word are normally in English.
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.
But if the software show 2021-03-02, I unambiguously know which it is.
Point noted.
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.
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.
[deleted]
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.
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.
> Not everything logical works with humans
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
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
My ¢2: you are %100 right.
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.
Is dm used widely wherever you’re located?
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.
Europe and China disagree with you.
It's time to come clean, I love you ISO8601 and I always have. You complete me.
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.
But it's not always unambiguous. ISO-8601 supports local time. It's only an unambiguous timestamp of the time zone is included.
> The US format is indeed awful but so is the European one really
There are many different European formats, some countries even use (a slightly modified version of) ISO-8601, ex. in the Nordics.
There are many different European formats, some countries even use (a slightly modified version of) ISO-8601, ex. in the Nordics.
> although the concept of months isn't really useful at all.
Made me chuckle, but I agree.
Made me chuckle, but I agree.
Date formats are pure fun.
['en-US','en-IE','en-GB','en-ZA','de-DE','es-ES','nl-NL','pl-PL','ru-RU','cs-CZ','sv-SE','fi-FI','lv-LV']
.forEach(lang => console.log(lang + ': ' + new Date('2020-02-04').toLocaleDateString(lang, {day:'numeric', month:'numeric', year:'numeric'})))
en-US: 2/4/2020
en-IE: 4/2/2020
en-GB: 04/02/2020
en-ZA: 2020/02/04
de-DE: 4.2.2020
es-ES: 4/2/2020
nl-NL: 4-2-2020
pl-PL: 4.02.2020
ru-RU: 04.02.2020
cs-CZ: 4. 2. 2020
sv-SE: 2020-02-04
fi-FI: 4.2.2020
lv-LV: 2020.02.4.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.
This feels better than the other way around.
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.
This feels better than the other way around.
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.
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.
https://en.m.wikipedia.org/wiki/ISO_8601
So I would generally advise against accepting iso formatted dates and instead decree a single date format.
https://en.m.wikipedia.org/wiki/ISO_8601
> The 2000 version allowed writing "--04-05" to mean "April 5"[23] but the 2004 version does not allow omitting the year when a month is present.
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.
Both of these points are mentioned in the article.
Here's an interesting date format most of HN probably haven't heard of; military date-time-groups[1].
Advantages:
- it's much more compact than ISO8601.
- the most significant information is first; the date.
- the second-most significant information is second; the time.
- the timezone is a single alphanumeric character.
- when military paperwork has a box at the top that says "DTG", everyone knows the format.
- I'm pretty sure it's a standard across all NATO militaries.
[1] https://en.wikipedia.org/wiki/Date-time_group#Military_Date_...
[2] https://en.wikipedia.org/wiki/List_of_military_time_zones
270009LFEB21
Advantages:
- it's much more compact than ISO8601.
- the most significant information is first; the date.
- the second-most significant information is second; the time.
- the timezone is a single alphanumeric character.
- when military paperwork has a box at the top that says "DTG", everyone knows the format.
- I'm pretty sure it's a standard across all NATO militaries.
[1] https://en.wikipedia.org/wiki/Date-time_group#Military_Date_...
[2] https://en.wikipedia.org/wiki/List_of_military_time_zones
I never heard of this before. It looks like an awful brain teaser, like an extension of the American middle-endian format to the extreme.
ISO 8601: [YYYY][MM][DD][hh][mm][tz] (0 1 2 3 4 TZ)
Military DTG: [DD][hh][mm][tz][MM][YY] (2 3 4 TZ 1 0)
ISO 8601: [YYYY][MM][DD][hh][mm][tz] (0 1 2 3 4 TZ)
Military DTG: [DD][hh][mm][tz][MM][YY] (2 3 4 TZ 1 0)
I like how the first paragraph ends with
"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.
"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.
https://tools.ietf.org/html/rfc7231#section-7.1.1.1
https://tools.ietf.org/html/rfc7231#section-7.1.1.1
It is a good format for sorting, but misses the point of use. As humans, we want to read the most significant data to our use case first.
The author confuses value to the reader with magnitute. In normal numbers, they happen to be the same thing.
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
You're just going to be seeing a heap of noise before you see the actual number you care about.
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
The author confuses value to the reader with magnitute. In normal numbers, they happen to be the same thing.
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
You're just going to be seeing a heap of noise before you see the actual number you care about.
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
> 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.
> 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.
--
[0] - https://en.wikipedia.org/wiki/Focal_point_(game_theory)
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.
--
[0] - https://en.wikipedia.org/wiki/Focal_point_(game_theory)
Date/Time is frequent topic[0] for me.
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.
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.
> And the American format just makes no sense
> 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.
> 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.
Off topic, but I can't resist: Using Comic Neue with Comic Sans as fallback must be the typographic equivalent of russian roulette.
I would absolutely not use this for IT purposes if I could avoid it.
The simple reason is that I have been bitten by time zone shenanigans way too often.
The same stands for databases always use timestamptz and not just timestamp.
Every frontend framework has functionality to properly and reliably format dates for a given locale.
As for filenames. It contains a space which is a pita for command line use.
The simple reason is that I have been bitten by time zone shenanigans way too often.
The same stands for databases always use timestamptz and not just timestamp.
Every frontend framework has functionality to properly and reliably format dates for a given locale.
As for filenames. It contains a space which is a pita for command line use.
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...
> As for filenames. It contains a space which is a pita for command line use.
The biggest problem I see is the time notation part using colons. Windows still doesn't allow using them in filenames in most places.
The biggest problem I see is the time notation part using colons. Windows still doesn't allow using them in filenames in most places.
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"."
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.
This is why I rejected iso-8601 and developed my own for https://github.com/kstenerud/concise-encoding/blob/master/ct...
Examples:
2019-8-5 : August 5, 2019
-300-12-21 : December 21, 300 BC (proleptic Gregorian)
12:05:50.102 : 12:05:50 and 102 milliseconds UTC
4:00:00/Asia/Tokyo : 4:00:00 Tokyo time
2019-01-23/14:08:51.941245 : January 23, 2019, at 14:08:51 and 941245 microseconds, UTC
1985-10-26/01:20:01.105/America/Los_Angeles : October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time
25192-11-01/03:00:00/48.86/2.36 : November 1st, 25192, at 3:00:00, at whatever is in the place of Paris at that time (global coordinates 48.86, 2.36)
- 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.
This is why I rejected iso-8601 and developed my own for https://github.com/kstenerud/concise-encoding/blob/master/ct...
Examples:
2019-8-5 : August 5, 2019
-300-12-21 : December 21, 300 BC (proleptic Gregorian)
12:05:50.102 : 12:05:50 and 102 milliseconds UTC
4:00:00/Asia/Tokyo : 4:00:00 Tokyo time
2019-01-23/14:08:51.941245 : January 23, 2019, at 14:08:51 and 941245 microseconds, UTC
1985-10-26/01:20:01.105/America/Los_Angeles : October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time
25192-11-01/03:00:00/48.86/2.36 : November 1st, 25192, at 3:00:00, at whatever is in the place of Paris at that time (global coordinates 48.86, 2.36)
yyyy-mm-dd is so nice you can just work with strings for your date stuff, converting to objects and back is tedious
Shameless plug: I built a python library to do exactly that https://pypi.org/project/yyyy-mm-dd/
Shameless plug: I built a python library to do exactly that https://pypi.org/project/yyyy-mm-dd/
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.
As close to canonical as you can get.
As close to canonical as you can get.
You can specify an interval as start/duration, start/end, or duration/end.
So you could specify a negative offset as a duration and the end time.
P2H/2021-02-26T13:30Z is two hours prior or T11:30Z on the same date.
So you could specify a negative offset as a duration and the end time.
P2H/2021-02-26T13:30Z is two hours prior or T11:30Z on the same date.
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.
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.
Of course even then, yyyy-mm-dd is best.
Of course even then, yyyy-mm-dd is best.
[deleted]
Has anyone succeeded in configuring GNU/Linux to consistently output dates in ISO 8601 format? A partial solution involves...
ls -l --time-style=full-iso
git log --date=iso
date --iso-8601=s # or date --rfc-3339=s
export TIME_STYLE='long-iso'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).
> a lesser-known date format called ISO 8601
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)
* JS, Python, Ruby, PostgreSQL,...
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)
* JS, Python, Ruby, PostgreSQL,...
I invented for myself this one: 2021-02-26_08-30-00_
And never looked back. Because since then I have no problems with dates anymore.
If there is a need for 'ms' you can add them in the end or add more sections for more precision.
For me it solves it.
And never looked back. Because since then I have no problems with dates anymore.
If there is a need for 'ms' you can add them in the end or add more sections for more precision.
For me it solves it.
One day you'll need to read a date written by someone else.
Or perhaps one day you'll need to read this one :)
If I meet another date format I convert it to this one when possible.
For instance I setup this date format for MacOS in Settings->Language & Region->Advanced->Dates: this way:
Short: y-MM-dd
Medium: y-MM-dd
Long: y-MM-dd_HH-mm-ss
Full: EEEE,y-MM-dd_HH-mm-ss
You just put those strings there and it should work.
In terminal you can do it too:
date "+%Y-%m-%d_%H-%M-%S_"
or
datetime=$(date "+%Y-%m-%d_%H-%M-%S_")
If I meet another date format I convert it to this one when possible.
For instance I setup this date format for MacOS in Settings->Language & Region->Advanced->Dates: this way:
Short: y-MM-dd
Medium: y-MM-dd
Long: y-MM-dd_HH-mm-ss
Full: EEEE,y-MM-dd_HH-mm-ss
You just put those strings there and it should work.
In terminal you can do it too:
date "+%Y-%m-%d_%H-%M-%S_"
or
datetime=$(date "+%Y-%m-%d_%H-%M-%S_")
At best this is incomplete.
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.
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'd guess most people, at least in Europe, learn British English, so US format of MM/DD is not really intuitive.
[deleted]
I was going to say this is a lot more readable than that other date/time format:
2021-02-26T12:25:04Z
2020-01-30T03:14:15+05:00
[deleted]
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.
My biggest complaint is that Windows doesn't allow ":" in file names. I just substitute "-", which is good enough, but not standard.
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.
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!
Great format, but once 2032 rolls around everyone will go back to a 2 digit shorthand for the year.
Because humans are lazy.
In my opinion, YYYY-MM-DD is the last unambiguous date format left.
I hold the line, and I will die on this hill.
I hold the line, and I will die on this hill.
I agree with this statement. We've started using it in our API calls.
26 II 2021
Job done
Job done
What about the Y10k bugs?
Even the xkcd https://xkcd.com/1179/ does not mention or gets wrong that
yyyymmdd
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)
yyyymmdd
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)
"I can't remember the date to fill out this form. Can you help me, but give me the least informative part first?"
While on the subject of time, could you Americans pretty please stop believing that the week starts on Sunday? It's just as wrong as your date format.
"Americans" didn't invent that idea.
The Hebrews did -- a long, long, long time ago.
Sunday is the first day of the week in almost all of the Americas, Japan, South Korea, and China.
Monday is the first day in Europe and some (relatively) recent European colonies (e.g., India).
The numbering of the days of the week is purely arbitrary. It makes no sense to claim that a particular ordering is "wrong".
If one goes by the sheer number of people who use a particular numbering, Americas + China comfortably exceeds Europe + recent European colonies.
The Hebrews did -- a long, long, long time ago.
Sunday is the first day of the week in almost all of the Americas, Japan, South Korea, and China.
Monday is the first day in Europe and some (relatively) recent European colonies (e.g., India).
The numbering of the days of the week is purely arbitrary. It makes no sense to claim that a particular ordering is "wrong".
If one goes by the sheer number of people who use a particular numbering, Americas + China comfortably exceeds Europe + recent European colonies.
China and Japan have Sunday as the first day since the 4th and 8th century respectively: http://chartsbin.com/view/41671.
So presumably, you come from a Europe-centric view: http://chartsbin.com/view/41671
So presumably, you come from a Europe-centric view: http://chartsbin.com/view/41671
China does? I'm Chinese and I'm pretty sure Chinese consider Monday to be the start.
Not according to:
https://unicode-org.github.io/cldr-staging/charts/38/supplem...
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.
https://unicode-org.github.io/cldr-staging/charts/38/supplem...
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.
Which is weird, because "god rested on the seventh day" and the Christian religion believes that to be Sunday, so it is the last day of the week.
Why does the US think that the week starts on Sunday?
Why does the US think that the week starts on Sunday?
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.
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.
Ah, sorry. Then I am misinformed. The locale "zh_CN" does give me Sunday as the first, which seems then misaligned with actual practice.
Interesting context for this on Wikipedia
https://en.wikipedia.org/wiki/Chinese_calendar#Week
https://en.wikipedia.org/wiki/Chinese_calendar#Week
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
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
> sunday is 7
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.
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.
The problem is that the US directs how much of my software is built.
Any choice is arbitrary. What is a week to the solar system? The only things that are real are days and years.
International Fixed Calendar is an alternative.
https://en.wikipedia.org/wiki/International_Fixed_Calendar
https://en.wikipedia.org/wiki/International_Fixed_Calendar
What is a day in the solar system? What is anything anywhere anyway?
That’s not the point.
The point is that in the US people typically work Mon-Fri and loaf around Sat-Sun (weekend) and yet the week starts in Sundays.
It’s infuriating.
That’s not the point.
The point is that in the US people typically work Mon-Fri and loaf around Sat-Sun (weekend) and yet the week starts in Sundays.
It’s infuriating.
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.
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.
So now when we rest, both the Jews and the Christians get their favorite day off and yay, we have a two-day weekend.
If your weekend is Fri-Sat then by all means start your week on Sunday.
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.
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.
It is a capitalist plot with a time machine, given that the convention goes back for millennia.