Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO 8601: a better date format

kirby.kevinson.org

Post reply on HN
Print view View original

261–270 of 437 posts

Re: ISO 8601: a better date format

#261

Post by knorker »

bombcar wrote: post #208
lostlogin wrote: post #147

Earlier quoted context omitted.

> 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.

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.

So write YYYY-MM-DD!

But also, the most sacret of all days has been honored by the one day of the year "said properly" fourth of july!

Re: ISO 8601: a better date format

#262

Post by TeMPOraL »

cesarb wrote: post #248
TeMPOraL wrote: post #116

Earlier quoted context omitted.

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…

> 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 pro…

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.

Re: ISO 8601: a better date format

#263

Post by anoncake »

TeMPOraL wrote: post #241
MaxBarraclough wrote: post #222

Earlier quoted context omitted.

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 ?

That's missing the point of pressuring the other side to adopt ISO 8601. (And in general case, of electronic documents with wider audience, using 3/Nov/2021 excludes people who don't know English (or the language in which you encoded the name of the month).)

The vast majority of documents are written in a language anyway so you can safely encode the date in it. Does any other language even have two different, conflicting date formats like that?

Re: ISO 8601: a better date format

#264

Post by InfiniteRand »

rswail wrote: post #246
Turing_Machine wrote: post #186

Earlier quoted context omitted.

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.

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?

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.

Re: ISO 8601: a better date format

#265

Post by dingaling »

jiggawatts wrote: post #6

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 i…

> only the other 96% of the planet

Ahem, ISO8601 fails for Taiwan and Japan...

Re: ISO 8601: a better date format

#266

Post by InfiniteRand »

yokaze wrote: post #48
m_eiman wrote: post #29

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.

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

Interesting context for this on Wikipedia

https://en.wikipedia.org/wiki/Chinese_calendar#Week

Re: ISO 8601: a better date format

#267

Post by TeMPOraL »

anoncake wrote: post #263
TeMPOraL wrote: post #241

Earlier quoted context omitted.

That's missing the point of pressuring the other side to adopt ISO 8601. (And in general case, of electronic documents with wider audience, using 3/Nov/2021 excludes people who don't know English (or the language in which you encoded the name of the month).)

The vast majority of documents are written in a language anyway so you can safely encode the date in it. Does any other language even have two different, conflicting date formats like that?

English is the only one with conflicting date formats I can think of (US vs UK), but in case of government and corporate documents, those are sometimes bilingual - with form labels in the primary language having a small-font translation to English below.

(Real use case: I recently sent a Polish equivalent of OSHA form to my line manager in UK, and I used a bilingual version. As you can imagine, I set the example by filling my part of the document using ISO 8601 for dates, so that once the document returns to the Polish corporate office, there won't be any possible confusions.)

Re: ISO 8601: a better date format

#268

Post by fatnoah »

inetknght wrote: post #57
jiggawatts wrote: post #6

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 i…

> 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 somethin…

>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.

Re: ISO 8601: a better date format

#269

Post by lovelyviking »

lazyasciiart wrote: post #113
lovelyviking wrote: post #84

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.

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_")

Re: ISO 8601: a better date format

#270

Post by systemvoltage »

knorker wrote: post #124
systemvoltage wrote: post #28

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 imp…

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.

I’ve never read anywhere on any product dimensions written in decimeter. Show me one and prove your point.
Post reply on HN