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

421–430 of 437 posts

Re: ISO 8601: a better date format

#421

Post by dragonwriter »

matheusmoreira wrote: post #390
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.

> 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. Always wondered about this too. How can people implement a standard if they can't freely access and reference it? It's the 21st century. Why can't they just publish the document on the internet just like the IETF does?

> How can people implement a standard if they can't freely access and reference it?

They pay for it, out of the money they expect to make on the implementation.

It's a little problematic for free implementations, but then for most standards much less so than the engineering going into the implementation which has an (opportunity, if nothing else) cost.

Re: ISO 8601: a better date format

#422

Post by justnotworthit »

> And the American format just makes no sense

> Maybe the European date format is better because the elements are in the order of relevance? > ... when we’re talking about events occuring on a day-to-day basis, however I can think of numerous cases when the year and the month are more relevant

I think that's the "sense" of the American one. It optimizes "metal sort" for month.

Re: ISO 8601: a better date format

#423

Post by gerikson »

amelius wrote: post #372
inetknght wrote: post #57

Earlier quoted context omitted.

> 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 somethin…

How can you take an international standard seriously when it is based on the number of years since some prophet of some specific religion was thought to be born?

I’m down for the years to be counted from the storming of the Bastille, personally...

Re: ISO 8601: a better date format

#424

Post by gerikson »

edoceo wrote: post #312
heipei wrote: post #306

Earlier quoted context omitted.

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?

Yes, if everyone follows ISO.

Re: ISO 8601: a better date format

#425

Post by Macha »

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.

UK/Ireland are pretty interchangeable about the seperators, but I'd guess D/M/Y has a strong lead over second place d/m/y, while d.m.y is trailing in last.

Re: ISO 8601: a better date format

#426

Post by skissane »

mywittyname wrote: post #357
andy-x wrote: post #277

Earlier quoted context omitted.

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.

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

If you are developing software purely for internal use, that might be okay. But I think it is bad idea if you are developing software for customers, including cloud-based services. There is a good chance at some point you are going to expose your internal timezone to the customer somehow, even by accident. If a customer in another country gets told something like "process X always happens at midnight UTC, and we can't change it", they'll generally be more accepting of that than if you say "process X always happens at midnight at our headquarters timezone, and we can't change it". The second makes you sound like you maybe don't take globalisation completely seriously.

Even developing software purely for internal use, your headquarters timezone may change. Maybe the company gets acquired. Maybe it just decides to move to a lower cost or more business-friendly location (e.g. Oracle's recent relocation from California to Texas). A lot of stuff is going to stick with the old headquarters timezone because changing it is just too hard. But new stuff people may well choose the new headquarters timezone instead. Now you have two standard timezones to deal with!

That's why: just leave everything as UTC internally. Convert to/from user's preferred time zone at time of display and data entry. That works for almost everything, except for applications which need to schedule meetings, work rosters, class timetables, etc. For those kinds of applications, the application needs to actually save the timezone with the data, and support different records belong to different timezones.

Re: ISO 8601: a better date format

#427

Post by FooBarWidget »

gurkendoktor wrote: post #125
luplex wrote: post #58

Earlier quoted context omitted.

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.

I've learned Chinese for fun. It's great that I can now read a few more Go/C++ READMEs on GitHub, but other than that, I can't imagine what advantage it has? Maybe there'd be one if I came from a poorer manufacturing country? even China commentators in Western media are often completely clueless about the language. If these jobs don't require Chinese fluency, then which ones do? And even then, it'd be much easier to…

Actually, many Chinese people mock western commentators for how bad their takes are. Those commentators often have a superficial or highly western-centric understanding of things in China, resulting in wrong or incomplete interpretations. Lack of Chinese language understanding is a contributing factor.

That doesn't stop those commentators from getting lucrative jobs. Apparently, western audiences don't care to verify whether what commentators say are accurate, or audiences just don't care whether it's accurate. There are no consequences to even years of inaccurate commenting. So I guess if you have no professional pride, then yes you can get away with not learning Chinese.

Re: ISO 8601: a better date format

#428

Post by account42 »

Having mm/dd/yyyy and dd.mm.yyyy wouln't even be so bad if people did not also write mm.dd.yyyy and dd/mm/yyyy and mm-dd-yyyy and dd-mm-yyyy and mm.dd.yy and dd/mm/yy and mm-dd-yy and dd-mm-yy and mm.dd and dd.mm and mm/dd and dd/mm.

Of course even then, yyyy-mm-dd is best.

Re: ISO 8601: a better date format

#429

Post by account42 »

leapsecondsgood wrote: post #407
btilly wrote: post #393

Earlier quoted context omitted.

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

Accuracy of what? For 12:00 to be at noon on average? That's what timezones are for and they also already change. Just add leap seconds to the timezone offset instead.

Meanwhile leap seconds decrease accuracy when measuring long time periods unless you explicityly remove them again.

Re: ISO 8601: a better date format

#430

Post by account42 »

sixothree wrote: post #399
jeff-davis wrote: post #286

Earlier quoted context omitted.

Lexicographic sorting does not work for numbers of different lengths, e.g. "100" and "9".

On Windows Explorer it does. Not sure why other systems and apps have not adopted this.

They have. There are even different variants of human/version sort. They are of course not as straight forward as a simple lexicographical sort so not everything is going to implement one.
Post reply on HN