In my opinion, YYYY-MM-DD is the last unambiguous date format left.
I hold the line, and I will die on this hill.
ISO 8601: a better date format
231–240 of 437 posts
Re: ISO 8601: a better date format
#232Earlier quoted context omitted.
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 2021-02-26T06:22:59+00:00 2021-02-26T06:22:59Z 20210226T062259Z No…
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 ni…
> (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.
Re: ISO 8601: a better date format
#233I 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
Re: ISO 8601: a better date format
#234At 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.
> 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.
Re: ISO 8601: a better date format
#235Earlier quoted context omitted.
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.
Re: ISO 8601: a better date format
#236Earlier quoted context omitted.
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 !
> 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).
Re: ISO 8601: a better date format
#237Earlier quoted context omitted.
How about french? 99 is four twenties nineteen, 79 is sixty nineteen. Languages are fun and fascinating.
And since the French say ten nine instead of nineteen, it becomes four twenties ten nine.
But nineteen is just "nine and ten" with the "and" removed.
English has a word for twenty and its used in the French way "Four score and seven years" is "quatre-vingts et sept".
Re: ISO 8601: a better date format
#238Earlier quoted context omitted.
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.
Well you're actually saying "the 27th day of the month of February" and removing some of the small joining words of various flavors. :) /s
Re: ISO 8601: a better date format
#239Earlier quoted context omitted.
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 (local…
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 ove…
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.
Re: ISO 8601: a better date format
#240Free 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…
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.
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.