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

181–190 of 437 posts

Re: ISO 8601: a better date format

#181

Post by Semaphor »

misterS wrote: post #108
jacobolus wrote: post #49

Earlier quoted context omitted.

Mac Firefox and Mac Chrome both break a bunch of keyboard shortcuts if you use a non-US-ANSI keyboard. Safari handles alternate layouts correctly. Just yesterday I learned that on an ISO Spanish keyboard, both of those browsers will pop up a help menu for ⌘⇧7. The logic goes: ⇧7 means / on a Spanish ISO keyboard, and ⇧/ means ? on a US-ANSI keyboard, therefore ⌘⇧7 is by the transitive property of inter-layout shift f…

Stuff like this is the reason why I, as a non-american software engineer, use `US_en` layouts on all my machines.

I use EurKey [0] (I think this was actually recommended to me on HN) so I have easy "AltGr" access to German characters like öüß. Sadly some tools (most notably Microsoft’s) have hardcoded shortcuts for some of those, which is really annoying.

[0]: https://eurkey.steffen.bruentjen.eu/

Re: ISO 8601: a better date format

#182

Post by inetknght »

antihero wrote: post #136

It is a good format for sorting, but misses the point of use. As humans, we want to read the most significant data to our use case first. The author confuses value to the reader with magnitute . In normal numbers, they happen to be the same thing. In most cases, we want to discern between days first, them months, then years. If you look at a list of dates: 2021-01-01 2021-01-02 2021-01-03 2021-01-04 You're just going…

> In most cases, we want to discern between days first, them months, then years. If you look at a list of dates:

> 2021-01-01

> 2021-01-02

> 2021-01-03

> 2021-01-04

With you so far.

> You're just going to be seeing a heap of noise before you see the actual number you care about.

100% disagree. There's less noise here than having days from other months or years mixed in. If there's noise here then either I am on the wrong page and need to navigate to the correct year or else the data I want has few data points.

> If you consider that days are the most valuable, then months, then years, you get the UK/European format.

> 01/01/2021

> 02/01/2021

> 03/01/2021

> 04/01/2021

Maybe. Your list is contrived. Here's another.

01/01/2021

01/03/2021

01/04/2020

01/10/2021

01/11/2019

02/01/2021

02/13/2019

02/20/2021

Those numbered days are completely irrelevant to each other in most circumstances. Now other months and even other years are mixed in. Expand this list to 1000 data points and good luck figuring out where your data's at.

Re: ISO 8601: a better date format

#183

Post by fogihujy »

silvestrov wrote: post #100
Mordisquitos wrote: post #72

Earlier quoted context omitted.

Another great thing about 2021-03-11 is that, even putting aside its technical advantages, it is (probably) intuitively understandable to any literate person even if they have never seen it before and, most importantly, it is almost immune from confusion because (hopefully) nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American intuitive expectation of month coming before day, and the Wo…

Another great thing about 2021-03-11 is that it ascii sorts correctly.

This is the big one when it comes to sorting files and directories on disk. It makes sorting and finding what you look for so much easier.

Re: ISO 8601: a better date format

#184

Post by BoppreH »

sirn wrote: post #175
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…

I think because it would defeat the portability of a timestamp because Asia/Tokyo isn't constant and you cannot lookup the offset without relying on external database that takes in ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in zoneinfo changes depending on day of a year, and sometimes even hour of a day, and the database of timezone is constantly updated (latest zoneinfo is version 2021a). So while…

I knew about TAI but TAI64 is new to me, thanks.

About the TZ database, don't all date lookups require accessing it? If I schedule a meeting in Asia/Tokyo now, and the database tells me it's +09:00, I still have to remember it's Asia/Tokyo because the offset may change 5 minutes before the meeting.

Analyzing the timestamp requires a TZ database, but that's calendars for you; the encoding is not going to change this. We don't actually know when the meeting will take place until it does.

I'm still struggling to come up with a situation where including only the offset is the correct approach, which makes ISO 8601's decision puzzling.

Re: ISO 8601: a better date format

#185

Post by happymellon »

jacobolus wrote: post #92
Mordisquitos wrote: post #72

Earlier quoted context omitted.

Another great thing about 2021-03-11 is that, even putting aside its technical advantages, it is (probably) intuitively understandable to any literate person even if they have never seen it before and, most importantly, it is almost immune from confusion because (hopefully) nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American intuitive expectation of month coming before day, and the Wo…

I have seen non-Americans write YYYY/DD/MM before. Hyphens are key here.

That is horrifying.

I am glad I have never met these people.

Re: ISO 8601: a better date format

#186

Post by Turing_Machine »

FooBarWidget wrote: post #86
yokaze wrote: post #48

Earlier quoted context omitted.

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

China does? I'm Chinese and I'm pretty sure Chinese consider Monday to be the start.

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.

Re: ISO 8601: a better date format

#187

Post by Symbiote »

akvadrako wrote: post #164
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…

Probably those are from the locales package? en-dk is the best one, it is Europe standard english which I think fits all your requirements for Saneland.

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.

Re: ISO 8601: a better date format

#188

Post by Gys »

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 is exaclty this attitude what makes the datetime format in Golang extremely difficult to use. I always have to double check my formatting. I like the basic idea very much, but its logic only works for 'local' Americans.

    The reference time used in the layouts is the specific time:
    Mon Jan 2 15:04:05 MST 2006
    which is Unix time 1136239445. Since MST is GMT-0700, the reference time can be thought of as
    01/02 03:04:05PM '06 -0700`
Golang was not meant to become a big international language from the start? Just a fun internal Google project ;-)

Re: ISO 8601: a better date format

#189

Post by PowerBar »

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.

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.

Post reply on HN