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

101–110 of 437 posts

Re: ISO 8601: a better date format

#101

Post by readflaggedcomm »

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 more obnoxious to be lectured by people who think "June 3rd, 2021" isn't shorthand for "AD 2021 June 3rd", which is proper logical and sorting order.

Re: ISO 8601: a better date format

#102

Post by jpetso »

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…

Bah, humbug. I moved to Canada almost a dodecade ago and despite all person heights and interior design stuff being denominated in imperial units, getting the hang a grasp of any multiples is no more intuitive than in metric units. Metres work similarly well as feet, that is, not great for nontrivial amounts.

Within a certain range you'll do fine either way. Outside of a certain range you'll always need a measuring tape, or you just had a had a lot of practice, eyeballing and learned habits going in.

Re: ISO 8601: a better date format

#103

Post by fredzel »

gorgoiler wrote: post #53

At best this is incomplete. Most humans talk about (month, date) tuples. US dates are big endian and written mm/dd. 12/25, 10/1, 2/28. They are elegant and compact and visually sort in the correct way eleven times out of twelve ( 11/12 .) Short UK dates are spoken as “Jan 9th” “8th of March” and written as such, or sometimes “Feb 9”. I find them very less pleasing. Longer UK dates in Guardian format are prettier: 3 J…

I'd guess most people, at least in Europe, learn British English, so US format of MM/DD is not really intuitive.

Re: ISO 8601: a better date format

#104

Post by jlelse »

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…

This reminds me about Americentrism: https://jlelse.blog/thoughts/2021/02/americentrism

America first!

Re: ISO 8601: a better date format

#105

Post by sebmellen »

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…

This is one of my biggest gripes with GNOME, along with the incredibly stupid lack of thumbnails in the file browser.

Re: ISO 8601: a better date format

#106

Post by jacobolus »

FeepingCreature wrote: post #62
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…

Another example of obnoxious American attitude: the TZ variable in POSIX. TZ=UTC+8. Is your system now set to the timezone UTC+8? No, it's set to UTC-8. Why? I don't know, but I suspect the people who developed this convention, who lived in the US, just didn't want to type a minus.

The TZ format counts how many hours behind UTC you are (how many hours should you add to get UTC time). The ISO format counts how many hours ahead of UTC you are. Neither choice is inherently correct, but the discrepancy is pretty annoying.

Use https://en.wikipedia.org/wiki/Tz_database names instead.

Re: ISO 8601: a better date format

#107

Post by kstenerud »

ISO-8601 was a good early attempt, but unfortunately it has some negative points:

- Only offset-based time zones are allowed (which are next to useless).

- Omitting the time zone defaults to local time, which renders the time ambiguous. Defaulting to UTC makes much more sense.

- BC dates are all offset by 1 ("-1" = 2 BC). I know the reasons for this, but this could have been moved to the implementation and not exposed to the user.

- Lots of silly things like fractional-minutes and multiple ways to represent the same data bloat the spec and implementations.

This is why I rejected iso-8601 and developed my own for https://github.com/kstenerud/concise-encoding/blob/master/ct...

Examples:

2019-8-5 : August 5, 2019

-300-12-21 : December 21, 300 BC (proleptic Gregorian)

12:05:50.102 : 12:05:50 and 102 milliseconds UTC

4:00:00/Asia/Tokyo : 4:00:00 Tokyo time

2019-01-23/14:08:51.941245 : January 23, 2019, at 14:08:51 and 941245 microseconds, UTC

1985-10-26/01:20:01.105/America/Los_Angeles : October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time

25192-11-01/03:00:00/48.86/2.36 : November 1st, 25192, at 3:00:00, at whatever is in the place of Paris at that time (global coordinates 48.86, 2.36)

Re: ISO 8601: a better date format

#108

Post by misterS »

jacobolus wrote: post #49
vbezhenar wrote: post #13

Earlier quoted context omitted.

It took many decades to widely adopt UTF-8. I think that one of the reasons was that US companies did not really care about character encodings, as it's not something they have to often deal with. Even today managing multiple keyboard layouts is a pain in most operating systems, it's buggy, it does not have enough configuration options, it's not convenient. Probably because most US developers never tried to use that…

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.

Re: ISO 8601: a better date format

#109

Post by eqvinox »

otherme123 wrote: post #75
jacobolus wrote: post #40

Earlier quoted context omitted.

I have taken to writing 11 March 2021 or similar whenever possible. But sure, 2021-03-11 is also fine, when trying to save something machine readable. The US conventions are indeed horrendous.

I also always write 11 मार्च 2021 or similar whenever possible. No problems so far.

I go with 「２０２１年０３月１１日」. Free bonus test included for whether software handles alternate numerals ;)

Re: ISO 8601: a better date format

#110

Post by em500 »

valenterry wrote: post #87

ISO 8601 contains durations and time intervals which are totally undervalued! ( https://en.wikipedia.org/wiki/ISO_8601#Time_intervals ) E.g.: 2021-05-01T12:00:00Z/P2H They are so convenient. Ever stored a tuple of two datetimes to model a time interval? E.g. a meeting that takes place on 2021-05-01T12:00:00Z and takes two hours? Don't! Instead, store it as an interval: "2021-05-01T12:00:00Z/P2H" Or are you creating a…

I agree it's undervalued. Sadly too few people are aware that a standard notation for time intervals even exists, and external software support is very sparse (e.g. lacking in Pandas, R, most SQL implementations). Which leads to too many devs rolling their own buggy solutions for datetime arithmetic.
Post reply on HN