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

51–60 of 437 posts

Re: ISO 8601: a better date format

#51

Post by systemvoltage »

wahern wrote: post #35
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…

30 years ago when most literature was either published recently (newspapers, magazines, etc), or the date of publication was mostly irrelevant (books), your argument makes sense. If you cared at all, what mattered was usually the month and day. For most of the literature people read in the 21st century, especially this past decade, the year is the most important part. People normally couldn't care less whether someth…

I think I need to labor on my point a bit more.

There are many use cases for dates. From publication date to planning vacation on a calendar. What is the most common use for a date? Calendar, I guess? The most frequently used dates we encounter are within +/- weeks from now. In a day to day use, YYYY is useless.

Re: ISO 8601: a better date format

#52

Post by pimlottc »

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.

Re: ISO 8601: a better date format

#53

Post by gorgoiler »

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

US dates inevitably have to be unambiguous about years. This is indeed unwieldy because a slashed triple — 3/4/22 — is used in the UK too. (The slashed pair is uncommon so it’s clear that 3/4 is an American date.)

Anything technical should indeed use ISO, but if you have an audience in a single locale it’s important to know your audience and localize (localise) accordingly.

Re: ISO 8601: a better date format

#54

Post by mattashii »

est wrote: post #16
k_sze wrote: post #5

Earlier quoted context omitted.

Until we hit year 10000, but yeah, that's still a looong time to go.

There's some proposal that this year 2021 is actually 12021, to make the year neutral of some specific religious event.

... which is funny, because the gregorian calendar is supposedly based on a compromise between some years that christ was supposedly born in (the chosen year 1 is none of those, according to research, as he was born in 6-4 BC [0]).

So now we have: another calendar, that has a starting year that is defined by subtracting an arbitrary number from a compromise between alledged years some person was born in.

I love how humanity has the capability to invent new things with increasing complexity.

[0] https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesu...

Re: ISO 8601: a better date format

#55

Post by SideburnsOfDoom »

rollulus wrote: post #27

At the risk of nitpicking, I prefer RFC 3339, which is a profile of ISO 8601. ISO 8601 provides room for things you typically don't want, e.g. dropping time zone offsets. While I'm typing this I realise that I've never actually read the ISO 8601 spec, like probably most people here, because it's not free. I cannot even be sure it really exists.

> I've never actually read the ISO 8601 spec, like probably most people here

Indeed. The comprehensive Wikipedia article on ISO8601 is as far as we go

https://en.wikipedia.org/wiki/ISO_8601

Thanks for pointing out rfc3339 - this appears to be the "useful part" of ISO8601 for data interchange.

https://tools.ietf.org/html/rfc3339

Re: ISO 8601: a better date format

#56

Post by lloeki »

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…

The best part is when someone tried to make it work for the other 96% of the world but failed for 2% of the dates (probably because the other locales got less testing, again very US centric), so one ends up with mixed US/EU dates (the latter often also uses / as a separator, as . is only used in some EU countries).

It's so much fun trying to retrospectively correlate fatal incident data and failing to make sense of anything because some dates are inconsistent. Of course those dates are all the ambiguous kind, otherwise it wouldn't be -that- hilarious /s.

Re: ISO 8601: a better date format

#57

Post by inetknght »

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 the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them...

As an American I can fully confirm that 3/11/2011 is obnoxiously ambiguous. It affects us. But most Americans (particularly outside of science / engineering fields) are too thick-headed to recognize the problem or think about ways to improve it.

So I do what I can. I don't even ask what time format something belongs in. I just write ISO8601 by default. If someone complains then I point them to the international standard and ask whether we want to be an internationally standards-compliant company.

One manager said that our customers aren't international. It was a reasoned argument and I like having customers. But all others drop the argument at "international company" and "standards-compliant"

Re: ISO 8601: a better date format

#58

Post by luplex »

CyberRabbi wrote: post #21
hannob wrote: post #9

There's another aspect you may not know about: It's close to how it's done in chinese, which is 2021年3月17日. They use different separators (the chinese words for year, month and day), but it's close enough. Given that china is the country with the largest population it may not be a bad idea to use something a large number of people will easily understand.

Maybe we should also start speaking Chinese since it may not be a bad idea to use something a large number of people will easily understand. Edit: this is not sarcasm. It’s simple logic, unless there is something wrong with learning other languages.

This is actually not wrong. China is already very important, and its influence is going to grow. Speaking and understanding Chinese well is a competitive advantage.

Re: ISO 8601: a better date format

#59

Post by rob74 »

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.

This article is primarily about the date format, and that doesn't have anything to do with the timezone, so it's a bit unfair to hold time zone issues against it. Some issues are also self-made because people (including people who write libraries, frameworks etc.) choose to store a date (e.g. somebody's birthday) as a datetime...

Re: ISO 8601: a better date format

#60

Post by eesmith »

kirbykevinson wrote: post #25
eesmith wrote: post #18

Earlier quoted context omitted.

How would you describe the accuracy and veracity of > "Here there’s only one correct way to write a date," given that there are multiple correct ways, and the way shown wasn't actually ISO 8601 but RFC 3339?

Yes, technically there are some edge cases where you can write things differently (apart from what you mentioned, one is, for example, writing the UTC time zone by Z vs +00:00 and another is adding additional precision to the date), but for the end user it's basically the same. Let's not ruin the illusion here :)

There's nothing wrong with leading with something like:

ISO 8601 is a complex specification because of the many different ways to describe times, dates and duration. Don't let that complexity throw you off! The ISO 8601 timestamp format is clean and elegant. These examples will use the widely used ISO 8601 profile known as RFC 3339, which I'll refer to simply as "ISO 8601".

No need for an illusion when synecdoche works.

Post reply on HN