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

221–230 of 437 posts

Re: ISO 8601: a better date format

#221

Post by euroderf »

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.

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.

Re: ISO 8601: a better date format

#222

Post by MaxBarraclough »

timvisee wrote: post #220
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…

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?

Re: ISO 8601: a better date format

#223

Post by ginko »

CyberRabbi wrote: post #64
monsieurbanana wrote: post #38

Earlier quoted context omitted.

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.

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

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

Re: ISO 8601: a better date format

#224

Post by alkonaut »

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.

Re: ISO 8601: a better date format

#225

Post by Symbiote »

akvadrako wrote: post #195
Symbiote wrote: post #187

Earlier quoted context omitted.

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.

en-dk has ISO 8601 though you're right it uses the comma. 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).

  % en_DK is used outside Denmark, as some sort of generic continental
  % European English locale.
And that's the nasty hack -- this should be defined in en_EU or similar.

Re: ISO 8601: a better date format

#226

Post by alkonaut »

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…

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.

Re: ISO 8601: a better date format

#227

Post by qayxc »

pimlottc wrote: post #52
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…

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 This is a bit more human-readable and closer to commonly-used forms of dates while still being completely unambiguous.

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

Re: ISO 8601: a better date format

#228

Post by bombcar »

young_unixer wrote: post #94

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

Salesforce does the same thing so I tell it I’m Latvia. It kinda works until it doesn’t.

Re: ISO 8601: a better date format

#229

Post by akvadrako »

Symbiote wrote: post #225
akvadrako wrote: post #195

Earlier quoted context omitted.

en-dk has ISO 8601 though you're right it uses the comma. 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). % en_DK is used outside Denmark, as some sort of generic…

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.

Post reply on HN