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

331–340 of 437 posts

Re: ISO 8601: a better date format

#331

Post by notatoad »

PowerBar wrote: post #189
knorker wrote: post #120

Earlier quoted context omitted.

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.

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.

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.

Re: ISO 8601: a better date format

#332

Post by lostlogin »

knorker wrote: post #261
bombcar wrote: post #208

Earlier quoted context omitted.

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!

Changing formats is just asking for a large event on 9 November.

Re: ISO 8601: a better date format

#333

Post by trinix912 »

yread wrote: post #145
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…

M/D/Y is a bit like the German way of reading numbers. 328 become three hundred, eight and twenty. Terrible

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

Re: ISO 8601: a better date format

#335

Post by bonzini »

richrichardsson wrote: post #128
CyberRabbi wrote: post #64

Earlier quoted context omitted.

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…

> 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

All of them can read the characters for year/month/day though.

Re: ISO 8601: a better date format

#336

Post by JdeBP »

fermienrico wrote: post #327
JdeBP wrote: post #320

Earlier quoted context omitted.

Nonsense. People have been commenting on how these two orderings are confusing for far longer than 20 years. Things made in the United States have had worldwide circulation for quite a while, now. Even if one has WWW tunnel vision, Markus Kuhn's WWW page on ISO 8601 has been around since 1995.

If you’re living in Berlin, it didn’t matter what US date format was 20 years ago. You’re missing the point that the globe is far more connected due to the internet.

No, you are missing the point that the globe was connected due to the Internet for far more than 20 years, as evidenced at least by the fact that one of the more widely known treatises on ISO 8601 on the World Wide Web dates from the middle 1990s. And that's merely the World Wide Web, not the worldwide computer networks and communications systems, where dates have been an issue, that pre-date the WWW. The idea that this issue is new because the world only got connected in the 21st century is baloney. Doubly so: The world got connected so that people in other countries saw each other's conventional date formats long before, and people have been discussing date format ambiguities for far more than 20 years.

Re: ISO 8601: a better date format

#337

Post by trinix912 »

Andruru wrote: post #177
cm277 wrote: post #99

Earlier quoted context omitted.

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.

Re: ISO 8601: a better date format

#338

Post by trinix912 »

LordHeini wrote: post #33

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.

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

Re: ISO 8601: a better date format

#339

Post by BoppreH »

kerblang wrote: post #317
BoppreH wrote: post #150

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

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…

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

Re: ISO 8601: a better date format

#340

Post by bobbylarrybobby »

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…

The country should be called Esperantonia
Post reply on HN