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

411–420 of 437 posts

Re: ISO 8601: a better date format

#411

Post by emergie »

Date formats are pure fun.

  ['en-US','en-IE','en-GB','en-ZA','de-DE','es-ES','nl-NL','pl-PL','ru-RU','cs-CZ','sv-SE','fi-FI','lv-LV']
    .forEach(lang => console.log(lang + ': ' + new Date('2020-02-04').toLocaleDateString(lang, {day:'numeric', month:'numeric', year:'numeric'})))
  en-US: 2/4/2020
  en-IE: 4/2/2020
  en-GB: 04/02/2020
  en-ZA: 2020/02/04
  de-DE: 4.2.2020
  es-ES: 4/2/2020
  nl-NL: 4-2-2020
  pl-PL: 4.02.2020
  ru-RU: 04.02.2020
  cs-CZ: 4. 2. 2020
  sv-SE: 2020-02-04
  fi-FI: 4.2.2020
  lv-LV: 2020.02.4.

Re: ISO 8601: a better date format

#412

Post by ProZsolt »

shpx wrote: post #370
aairey wrote: post #369

Earlier quoted context omitted.

NMP. :D

It can be a problem/nuisance if you're working with nuclear waste or orbits. It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed.

Not if you traveling by the speed of light

Re: ISO 8601: a better date format

#413

Post by BoppreH »

nayuki wrote: post #403
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…

You are conflating two separate issues. To address your first issue, ISO 8601 uses numeric time zone offsets because it is simple and reliable. It lets you interpret a timestamp offline, without needing an enormous database of names and rules, and without constant online updates due to political reasons as you said. Another way to think about it is like this: Suppose right now you schedule a future event that happens…

> You can think of ISO 8601 as basically this - a way to describe absolute points in global time without references to politically motivated definitions of local time zones.

But that's TAI. Any calendar is a consensus agreement and amenable to politics (see Samoa skipping a day in 2011 [0], and all the bizarre calendar changes of the 18th century).

ISO 8601 sounds simple and reliable, but only because it refused to adopt most of the human complexity of timezones. Kinda like "extended ASCII", that allowed programmers to pretend just a little longer that all characters can fit in 8-bits. And we don't have a Unicode for dates.

If Tokyo changes their DST rules or leap seconds happen, your simple and reliable offline countdown timer will be wrong. How is that acceptable for a calendar-based (i.e. human) format?

Or if I'm naming my files with ISO 8601 dates and relying on lexicographic sorting (as others in this thread suggested), I'll have gaps or overlaps after DST changes.

Am I crazy? I'm getting lots of disagreement, so I must be doing something wrong, but the more I think about it, the more I believe that ISO 8601 succeeded by stealthily sacrificing correctness.

[0]: https://www.bbc.com/news/world-asia-16351377

Re: ISO 8601: a better date format

#414

Post by geonic »

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.

That’s why I use it exclusively to prefix my file names. It’s sortable, easy to parse visually and always has the same length.

Re: ISO 8601: a better date format

#415

Post by dragonwriter »

nayuki wrote: post #403
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…

You are conflating two separate issues. To address your first issue, ISO 8601 uses numeric time zone offsets because it is simple and reliable. It lets you interpret a timestamp offline, without needing an enormous database of names and rules, and without constant online updates due to political reasons as you said. Another way to think about it is like this: Suppose right now you schedule a future event that happens…

> ISO 8601 uses numeric time zone offsets because it is simple and reliable.

But it isn't. It's unnecessary complexity because additional numeric zones offer no real information beyond what UTC-only provides when you want to “describe absolute points in global time without references to politically motivated definitions of local time zones.”

Re: ISO 8601: a better date format

#416

Post by Delk »

andy-x wrote: post #277
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.

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

In many contexts that doesn't really matter. Sure, from a programmer point of view that's a problem because there are potential cases with incorrect or ambiguous behaviour, but being able to sort files by date could be useful in cases where that level of correctness and granularity don't matter.

You might just have a bunch of files from around the year that you just know won't ever be that close together in time, and which you perhaps also only ever touch manually, not programmatically.

I once chaired a smallish organization, and I used to name the minutes of meeting files with ISO 8601 style. If you have a dozen or so files from throughout the year, having them reliably sorted can make them easier to find, but there's never a problem with time zones or basically anything with granularity greater than a day.

Usually, if you've got a situation where you need to worry about time zones or DST, identifying things with year-month-day style timestamps treated as strings would be too low-tech a solution anyway.

(FWIW, the practice of using ISO 8601 didn't last, presumably because non-technical people didn't find them that nice for one reason or another.)

Re: ISO 8601: a better date format

#417

Post by hanche »

alkonaut wrote: post #224

I wouldn’t call ddmmyy “European”. Many countries use yymmdd (nordics, for example) which is the iso order. And the order in which alphabetical or numerical sorting works out of the box. Other than inertia/tradition there is really no excuse for shuffling around a date in any other way.

In Norway, the current standard is dd.mm.yy. Before computers, it was d/m-yy (no leading zeroes). I come across yyyy-mm-dd once in a while, but it is sort of rare.

Re: ISO 8601: a better date format

#418

Post by brewmarche »

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…

Shouldn't it be /PT2H instead of /P2H?

Re: ISO 8601: a better date format

#419

Post by specialist »

CyberRabbi wrote: post #64
monsieurbanana wrote: post #38

Earlier quoted context omitted.

Sigh... I never remember the names of the logical fallacies, I have to look up them, thanks a lot. Anyways, here's yours: Slippery Slope.

Where’s the logical fallacy? More people natively speak Chinese than any other language in the world. If you want to maximize the exposure of your ideas, it’s only logical to render them in Chinese. It’s the same reason I prefer to distribute applications over the web. FYI: English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers. https://www.visualca…

> Where’s the logical fallacy?

This is terrific, thank you. So meta.

Other popular examples:

"Is this some kind or radical new therapy?" from What About Bob? https://youtu.be/0pKymngWgJw?t=50

McNaulty from The Wire https://www.youtube.com/watch?v=sIvsTXnik7Q

Re: ISO 8601: a better date format

#420

Post by justaj »

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.

Except on Android, since you may not have files with the ":" characters in it.
Post reply on HN