Live data from Hacker News

ISO 8601: a better date format

kirby.kevinson.org

351–360 of 437 posts

Re: ISO 8601: a better date format

#351

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…

+1 for a new locale, equivalent to C but with UTF-8, ISO DATE, ISO paper, ...

Re: ISO 8601: a better date format

#352

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…

+1 for a new locale, equivalent to C but with UTF-8, ISO DATE, ISO paper, ...

Also, Android had until version 5 an option to force ISO date/time format, but it was removed for some reason?

Re: ISO 8601: a better date format

#353

Earlier quoted context omitted.

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

It’s a representation of how us Americans talk - we rarely say 26th of February and instead say February 26 - and if necessary tack on the year. It feels exceptionally awkward to say 26 February, thought saying “twenty twenty one February 26” sounds very strange, too. But people are very good at verbally saying different than is written.

No native speaker but isn't 4th of July more common than July 4th?

Re: ISO 8601: a better date format

#354

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.

Pretty much all the standards bodies I know of are financed through sales of the standards documents. It's not a bad system, in the end the commercial entities who end up needing them most pay for their development and upkeep.

Re: ISO 8601: a better date format

#355

Earlier quoted context omitted.

Meters are "human scale". To say not is nonsense. And 3/2. Is that the future or the past? No way to know. Did you miss the meeting, or is it next week? "No one uses a decimeter"... What bubble do you live in? But please, lecture some more about cultures you don't understand.

I’ve never read anywhere on any product dimensions written in decimeter. Show me one and prove your point.

Show me a tv measured in cups.

Re: ISO 8601: a better date format

#356
post #227

Earlier quoted context omitted.

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.

> This is a bit more human-readable and closer to commonly-used forms of dates while still being completely unambiguous. A bit more human readable you say? So 1 фев 2021, 1 Lut 2021, or 2021 فبراير1 are readable to you? I don't know but to me that's just US-centric thinking all over again.

>2021 فبراير1

I was going to ragequit at you for copy+pasting something into google translate, as it's شُبَاط not فبراير.

but TIL, only in the Levant do we say شُبَاط apparently.

Re: ISO 8601: a better date format

#357
post #277
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.

Only true if you ignore timezones and DST (which most people do because it is unholy mess) or stick to UTC.

You don't need to stick to UTC, you just need to stick to a single timezone. Which is something that is generally true.

UTC just happens to be a good natural choice for eliminating timezones, but I've seen companies chose another tz as their standard.

Re: ISO 8601: a better date format

#358
post #307

Earlier quoted context omitted.

Is their punishment to be forced to parse "009" with the C language's strtoul() library function for all eternity? (-:

What's the problem with strtoul? Just make sure to pass 10 as the third parameter, not 0.

Maybe the punishment in hell should be to RTFM for the rest of eternity.

Re: ISO 8601: a better date format

#359
post #346
post #302

Earlier quoted context omitted.

There's a special place in hell for people that using variable length representations for time units that are meant to be consumed by machines. I think it's across the hall from the room for people who configure servers for anything besides UTC.

Where do you put the people who think that we should inflict leap seconds on UTC?

In a special room resting atop a centrifuge so they can spend eternity arguing with each other about how long they've been in there.

Re: ISO 8601: a better date format

#360

A note from the front line. I actually use 8601 dates in a date-heavy consumer product ( https://clubman.app ) and it’s hands down the feature I most consistently get user feedback on. It’s always “Why are the dates all American format? Can you change them to English?” And then I try to patiently explain that they’re actually international format. People seem to have internalised that any date format they find slight…

Another advantage to outputting 8601 dates is it's easy to mechanically parse - you can probably find some JS to rewrite the 8601 dates coming from the server into whatever the user's current locale is. Bonus points: if your timestamps are UTC, the frontend reformatting can even take timezones into account (such that an American and an Australian could correctly see different dates for the same timestamp).
Post reply on HN