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

211–220 of 437 posts

Re: ISO 8601: a better date format

#211

Post by bombcar »

nicoburns wrote: post #80
dfee wrote: post #68

Earlier quoted context omitted.

> It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them... only the other 96% of the planet. I’m not going to comment on the author, though I will acknowledge the abrasive, unhealthy attitude. Anyway, no. I don’t think there’s a clear “American” standard. Maybe there once was, but I’d just see a pile of numbers these days. It’s hostile to the consumer as it inheren…

It is American. In the UK, we'd write 11th March 2021. But I don't mind too much when it's non-ambiguous like this.

Is that also how you’d say it? If verbally asked what tomorrow is would you say “twenty seven February” or “twenty seventh February” or “twenty seventh of February”? Americans normally would say “February twenty seventh”.

Re: ISO 8601: a better date format

#212

Post by m_eiman »

bartvk wrote: post #168
gherkinnn wrote: post #93

Earlier quoted context omitted.

The problem is that the US directs how much of my software is built.

Don't you just use localization features of your API for this? I'm an iOS developer, and whenever I print dates, I just ask the system to print it, according to the system its locale.

Many developers do not. Especially month views tend to be hardcoded.

Re: ISO 8601: a better date format

#213

Post by BoppreH »

parhamn wrote: post #207
BoppreH wrote: post #184

Earlier quoted context omitted.

I knew about TAI but TAI64 is new to me, thanks. About the TZ database, don't all date lookups require accessing it? If I schedule a meeting in Asia/Tokyo now, and the database tells me it's +09:00, I still have to remember it's Asia/Tokyo because the offset may change 5 minutes before the meeting. Analyzing the timestamp requires a TZ database, but that's calendars for you; the encoding is not going to change this.…

Most of the time you’d just need their current timezone offset (not location) to convert the stored offset into, no?

The stored offset was just my best guess for what Tokyo's offset will be at that date, according to my current TZ database.

If the database changes, I have to go back and edit my timestamps (!), but I dont know which ones to edit because I didn't keep track of (1) which ones are +09:00 because of Tokyo, as opposed to Seoul, and (2) which ones were created with the old database.

Re: ISO 8601: a better date format

#214

Post by Mauricebranagh »

inetknght wrote: post #57
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…

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

Point them at the fiasco where NASA mixed up Imperia and Metric.

And also ask but why are we not targeting international customers.

Re: ISO 8601: a better date format

#215

Post by beowulfey »

andy_ppp wrote: post #201
jiggawatts wrote: post #192

Earlier quoted context omitted.

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

You're making the assumption that users know YYYY-MM-DD is the date format and not YYYY-DD-MM. I bet if you asked non-developers the answers you would get would be pretty random, probably more errors than the locale on their machine.

the point is, no program writes the date YYYY-DD-MM (or at least, it's very rare).

users who don't know what ISO 8601 is would learn, simply because when that format is used in software, it is consistent!

Re: ISO 8601: a better date format

#216

Post by tom_mellior »

saithound wrote: post #118
systemvoltage wrote: post #28

No one here is talking about practicality for non-software engineers which is probably 99.9% of the population. It might be fine for sorting and no one gives a shit about endianess. Common person would argue - why do they need to know the year first? Most people encounter dates in the same year, they already know we're in 2021 and it is not as important. Having to laboriously parse YYYY before getting to the most imp…

These "arguments by practicality " are almost always just-so stories. The Hungarians (and presumably the Chinese) have their own just-so stories about why YMD is the most practical order: you use dates mostly when you sort heating bills, invoices, or even fruit preserves, and in all those cases you need to sort by year first. Australians will tell you a tale about how "day before month" is human-scale, while "month b…

> The Hungarians (and presumably the Chinese) have their own just-so stories about why YMD is the most practical order: you use dates mostly when you sort heating bills, invoices, or even fruit preserves, and in all those cases you need to sort by year first.

I should note that the Hungarians (can't speak for the Chinese) obviously leave out the year when it's clear which year is meant.

Re: ISO 8601: a better date format

#218

Post by saithound »

majewsky wrote: post #171
sirn wrote: post #155

Earlier quoted context omitted.

金 from 金曜日 (Kinyōbi) means Friday. The letter correspond to the planet the weekday was named after, just like in English (金星 is Venus)

The planet-weekday combination is harder to see in English than e.g. in Romance languages like French because English derived its planet names from Roman gods, but its weekday names from Norse gods (e.g. Friday comes from Freya). German is similar, having Freitag for Friday (again from Freya) and Donnerstag for Thursday (from Thor).

Slightly off, but this is fun, so let me expand (along with a minor correction):

The days of the week were named after the seven classical planets of astrology (by the Romans, who in turn named the seven classical planets, and hence the days, after Roman deities).

The names were taken up by speakers of Germanic languages, and eventually underwent semantic loan translation: Germanic deities were substituted for the Roman ones (with the exception of Saturday). Some people say that the Germanic deities themselves were culturally identified as one and the same as the Roman deities, but we probably won't ever know for sure (interpretatio germanica, analogously to the interpretatio graeca, the identification of Egyptian, Roman and Greek deities [1]).

And now, a minor correction: The day of Venus, Friday bears the name of the Germanic goddess Frigg, who is not the same as the Norse goddess Freyja. The meeting of the two characters, in a debate against Loki, is described in the Poetic Edda [2].

[1] https://en.wikipedia.org/wiki/Interpretatio_germanica [2] https://en.wikipedia.org/wiki/Lokasenna

Re: ISO 8601: a better date format

#219

Post by globular-toast »

DZittersteyn wrote: post #96
globular-toast wrote: post #41

Earlier quoted context omitted.

Any choice is arbitrary. What is a week to the solar system? The only things that are real are days and years.

It makes sense to me that the weekend comes at the end of the week, but then again, I don't know what came first, the term "weekend" or the convention of Sunday being the start of the week in some countries

I think it's just one of those things that doesn't really make sense to anyone, but one way makes slightly more sense to some than others.

In reality there is no week end. The only periods that exist are days and years (and lunar cycles). Weeks are artificially constructed and it can begin and end whenever we want. I can see the sense in saying the week ends at the end of Sunday so the weekend is the bit before that. I can also see the sense in saying the week ends at the end of Saturday and the weekend is around that.

Re: ISO 8601: a better date format

#220

Post by timvisee »

TeMPOraL wrote: post #116
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…

Yup. I hate // AM/PM formats with a passion. Doesn't help that I work with UK teams now, and their "natural" date format is 3/11/2021, with meaning of 3 and 11 reversed to what they'd mean for Americans... sigh . ISO 8601 everything. I'm religious about it. I write it in messages, on government forms, anything that doesn't force me to use a different format. On a bit of my insistence, we use ISO 8601 notation for all…

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