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

401–410 of 437 posts

Re: ISO 8601: a better date format

#401

Post by sixothree »

emergie wrote: post #313
908B64B197 wrote: post #301

Earlier quoted context omitted.

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.

> it generates serious problems

So do time zones. So do leap seconds. So does the speed of light. I guess deal with it.

None of what you argued negates the post you replied to. He is right after all. Dates within the year are sortable by pretty much any system.

But most of all the format makes ISO 8601 quite easy for Americans to wrap their head around. So maybe stop complaining and look at 8601 as a possible solution to what you consider confusing and problematic.

Re: ISO 8601: a better date format

#402

Post by nayuki »

brnrr wrote: post #244

Here's an interesting date format most of HN probably haven't heard of; military date-time-groups[1]. 270009LFEB21 Translation: The 27th, 00:09, "L" timezone (+11, NATO timezone[2]), February, 2021. Advantages: - it's much more compact than ISO8601. - the most significant information is first; the date. - the second-most significant information is second; the time. - the timezone is a single alphanumeric character. -…

I never heard of this before. It looks like an awful brain teaser, like an extension of the American middle-endian format to the extreme.

ISO 8601: [YYYY][MM][DD][hh][mm][tz] (0 1 2 3 4 TZ)

Military DTG: [DD][hh][mm][tz][MM][YY] (2 3 4 TZ 1 0)

Re: ISO 8601: a better date format

#403

Post by nayuki »

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 at exactly 2025-07-20 13:30:00 in Tokyo time. Then you calculate exactly how many seconds in the future that event is (based on Tokyo's current time zone rules, assuming no political changes), and you start an offline countdown timer that has no Internet connection and no knowledge of time zones. 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.

As for the second issue regarding positive/negative leap seconds, this issue is not unique to ISO 8601. It stems from UTC, and afflicts every popular system for describing time-of-day. If you want to subtract dates reliably to calculate the physical (rather than calendrical) number of seconds, you want to use TAI (Temps Atomique Internationale).

Re: ISO 8601: a better date format

#405

Post by dragonwriter »

btilly wrote: post #393
wiml wrote: post #386

Earlier quoted context omitted.

UTC has leap seconds by definition. Conventional POSIXish epoch time is a little more complicated – typically, the length of a second varies.

I am fully aware. I also don't believe that when everything was adopted, that people realized how big a deal it would become for software, and systems driven by software. Every leap second, factories shut down. Just in case. Every leap second we face the possibility of a large chunk of the Internet going dark like happened in 2012. Computer programmers spend millions of dollars per year in aggregate dealing with the…

> Computer programmers spend millions of dollars per year in aggregate dealing with the possibility of leap seconds.

Millions of dollars in aggregate per year? Assuming that’s just the US, with ~4 million working programmers with a median pay of ~$86,000/yr or about $43/hr assuming about 2,000 working hours per year, that’s, if I’m not messing up the math, on the rough order of 1 minute per programmer per year, on the order of a couple hours per programmer per year if you bumped it to hundreds of millions. In either case, its a neglible share of programmer-hours.

Re: ISO 8601: a better date format

#406

Post by zeckalpha »

jiggawatts wrote: post #192
andy_ppp wrote: post #132

Earlier quoted context omitted.

Format the date on the frontend using date.toLocaleDateString() and let the browsers locale do the work for you (assuming you’re in JS and on the web).

Short of stepping through the JavaScript line-by-line, how do you tell the difference between these two dates? 3/11/2021 3/11/2021 The difference is one was formatted incorrectly, and the other was formatted correctly. One is 2021-03-11, the other is 2021-11-03. Even having been told that there's a difference, you cannot know which is which. Even if you think you know because you found an unambigious date like 31/11/…

31/11/2021 is quite ambiguous, I can’t find such a date on my calendar, by either notation.

I’ve scheduled cron jobs for February 31st, to have them tracked but disabled.

Re: ISO 8601: a better date format

#407

Post by leapsecondsgood »

btilly wrote: post #393
wiml wrote: post #386

Earlier quoted context omitted.

UTC has leap seconds by definition. Conventional POSIXish epoch time is a little more complicated – typically, the length of a second varies.

I am fully aware. I also don't believe that when everything was adopted, that people realized how big a deal it would become for software, and systems driven by software. Every leap second, factories shut down. Just in case. Every leap second we face the possibility of a large chunk of the Internet going dark like happened in 2012. Computer programmers spend millions of dollars per year in aggregate dealing with the…

for accuracy

Re: ISO 8601: a better date format

#408

Post by Leherenn »

boring_twenties wrote: post #350
JdeBP wrote: 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.

Error handling is pretty horrible. And also it happily accepts negative values.

Re: ISO 8601: a better date format

#409

Post by emergie »

bombcar wrote: post #208
lostlogin wrote: post #147

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.

Somehow the rest of the anglosphere doesn't use that format.

Re: ISO 8601: a better date format

#410

Post by dxdm »

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.

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

Things you take for granted are easy to overlook until they break.

Post reply on HN