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

311–320 of 437 posts

Re: ISO 8601: a better date format

#311

Post by JdeBP »

CuriousNinja wrote: post #234
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.

> never actually read the ISO 8601 spec ... because it's not free I was very surprised to discover this. Why are they charging money for the specification of a date format? I would expect standards like these to be published in public domain.

Aside from the fact that you are conflating copyright with price, note that many standards organizations charge money for copies of their standards documents.

ISO charges roughly 20 times the price of a paperback book for a 33 page document. You can buy BS/ISO 8601-1:2019 from the BSI for an even more exorbitant £246. Standards Australia will sell the older 2007 version to you for a mere AUD165.

But this is not special. All standards documents cost money from these organizations, from dates and times to electrical plugs. Treasure the fact that you can (for example) get (some) ECMA standards from ECMA for free. It isn't the norm.

Re: ISO 8601: a better date format

#312

Post by edoceo »

heipei wrote: post #306
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…

I don't know, I'm German and deal with US folks a lot, for me it's like this: Date written with slashes or dashes (3/11/2021 or 3-11-2021) implies US-based month/day/year. Date written with dashes and the year first and zero-padding (2021-03-11) implies year-month-day, aka ISO8601. Date written with dots and without padding (11.3.2021) implies my native format, day.month.year.

Isn't the point of ISO to eliminate that guess/search process and replace with 100% accuracy on read?

Re: ISO 8601: a better date format

#313

Post by emergie »

908B64B197 wrote: post #301
tpetry wrote: post #17

The article is missing one of the best features of iso 8601: it‘s string form is naturally sortable. You don‘t need any specific logic for sorting, so e.g. your filesystem will automatically sort files correctly if you prefix them with a iso 8601 date.

The standard American date format (MM/dd/yyyy) also somewhat has this property for a limited number of use cases. Sorting within a single year will work, sorting multiple years will place the same date adjacent to each other so it makes them easy to compare if you are printing out let's say sales data.

Americans using cal/foot/elbow/galon system of measurements is quirky, but bearable.

AM/PM thing is silly, but bearable.

Malformed MM[/-.]dd[/-.]yyyy date format is one of the most confusing thing I have ever encountered and it generates serious problems.

Re: ISO 8601: a better date format

#314

Post by rodelrod »

heipei wrote: post #306
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…

I don't know, I'm German and deal with US folks a lot, for me it's like this: Date written with slashes or dashes (3/11/2021 or 3-11-2021) implies US-based month/day/year. Date written with dashes and the year first and zero-padding (2021-03-11) implies year-month-day, aka ISO8601. Date written with dots and without padding (11.3.2021) implies my native format, day.month.year.

but then you get an email from an American living in Paris and it's 11/3/2021 with dashes and God knows what he meant.

Re: ISO 8601: a better date format

#315

Post by andy_ppp »

alexvoda wrote: post #239
andy_ppp wrote: post #198

Earlier quoted context omitted.

Okay, well I'm pretty sure for most apps I've worked on this has been fine according to business requirements and solved the problem of our users. Do you have statistics on which users have their locale's set wrongly and can you explain why the browser provides this functionality? Maybe you should campaign for it to be removed on their mailing lists? Also, should you want to change the locale (via a preference or ove…

That's why we have international standards. So that 1 version of right and all others are wrong. And no matter how arrogant it might seem, at least for computing use cases, ISO 8601 is right and other date formats are wrong. There are absolutely no usecases where the US date format makes sense. No, having it written in the order you prefer to pronounce it is not an argument. Especially not in the language where you h…

I don’t disagree, in an ideal world great, let’s get everyone to change to ISO8601. I’m a big fan. However until developers become in charge of all the decisions (imagine!) I’ve suggested a reasonable solution that most people can use to format dates in 99% of users locales with too much hassle. There are more interesting bridges to die on.

Re: ISO 8601: a better date format

#316

Post by JdeBP »

atoav wrote: post #12

As a european I use ISO 8601 for everything since about 5 years. One point is also: if you manually write a date, the easiest to remember part (the year) comes first, then the month (which is usually also easily remembered) and then the thing that you can forget at times. This feels better than the other way around.

I can beat that slightly. I have things with ISO 8601 dates written on them, by me, dating from 1986. Yes, I started using it before it was formally published as a standard. I initially used the basic format.

Re: ISO 8601: a better date format

#317

Post by kerblang »

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 time doesn't. In theory, that epoch time is absolute and I can display it localized to anybody's preferred locale later.

In that light, adding/substracting seconds is just adding/subtracting seconds, although I'm usually passing that work off to a date library, which I hope accounts for skipped seconds caused by leap seconds....

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?

Re: ISO 8601: a better date format

#318

Post by exporectomy »

MaxBarraclough wrote: post #222
timvisee wrote: post #220

Earlier quoted context omitted.

Yes! I constantly get complaints when using ISO 8601 on school documents. But I won't stop using it.

I guess the complaints are because the format is unfamiliar and strikes non-software people as being non-standard. Perhaps use a format like 3/Nov/2021 ?

Can still be ambiguous because "list." means October in Croatian but November in Czech. Also, "lip." is July in Polish but June in Croatian and "srp." Is July in Croatian but August in Slovak.

Maybe it's just Croatian that's ruining it for everyone.

Re: ISO 8601: a better date format

#319

Post by [deleted] »

dfox wrote: post #287
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 have read the actual ISO 8601 spec. It is somewhat typical wall of prose ISO standard that contains meaningful conformance distinctions which depend on two words in the middle of 10+ line paragraph. For me, more significant reason to prefer RFC 3339 constrained profile is that ISO 8601 does not only mean YYYY-MM-DDTHH:MM:SS.sss but also includes bunch of alternate syntaxes like YYYY-DDD. And I have one big issue wi…

[deleted]

Re: ISO 8601: a better date format

#320

Post by JdeBP »

systemvoltage wrote: post #98
progval wrote: post #88

Earlier quoted context omitted.

It's not just about years, and it's already explained in the article. When I see the date "02/03" or "02/03/2021", I can't tell if it means "March the 2nd" or "February the 3rd", because websites and software don't consistently detect (or even care) about my locale. But if the software show 2021-03-02, I unambiguously know which it is.

Point noted. We weren't so globally connected just 20 years ago, so if you were in US, you were used to MM/DD format and if you were anywhere else, you were used to DD/MM format. It was all local.

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.
Post reply on HN