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

141–150 of 437 posts

Re: ISO 8601: a better date format

#141

Post by bhaak »

3np wrote: post #122
eqvinox wrote: post #109

Earlier quoted context omitted.

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

> My desktop terminal prompt right now shows [金 19:58:22] - just a single character and as long as it's 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?

Re: ISO 8601: a better date format

#142

Post by roelschroeven »

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

Re: ISO 8601: a better date format

#143

Post by aib »

tom-jh wrote: post #31

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.

This has been my experience as well.

Sometimes I tell onlookers that it's an ISO standard.

Re: ISO 8601: a better date format

#144

Post by rhn_mk1 »

andy_ppp wrote: post #132
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…

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

> Date().toLocaleDateString() > Uncaught TypeError: Date().toLocaleDateString is not a function

That doesn't seem like a standard API call.

Re: ISO 8601: a better date format

#145

Post by yread »

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

Re: ISO 8601: a better date format

#146

Post by systemvoltage »

bhaak wrote: post #111
systemvoltage wrote: post #90

Earlier quoted context omitted.

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…

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

Re: ISO 8601: a better date format

#147

Post by lostlogin »

knorker wrote: post #120
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…

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.

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

Re: ISO 8601: a better date format

#148

Post by GordonS »

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…

You can change the display format, but I really wish M/D/Y wasn't the default - it's just too ambiguous.

Re: ISO 8601: a better date format

#149

Post by TeMPOraL »

andy_ppp wrote: post #132
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…

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.

Re: ISO 8601: a better date format

#150

Post by BoppreH »

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

Post reply on HN