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

171–180 of 437 posts

Re: ISO 8601: a better date format

#171

Post by majewsky »

sirn wrote: post #155
bhaak wrote: post #141

Earlier quoted context omitted.

> My desktop terminal prompt right now shows [金 19:58:22] - just a single character and as long as it's You're a bit cheating there :) It's one character that takes up 2 columns. You could get away with using the first 2 characters from the English names as they are unique. But I know that in English that's unusual but for example in German, the 2 letter abbreviation are the standard ones. You say weekday, but Google…

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

Re: ISO 8601: a better date format

#172

Post by yokaze »

FooBarWidget wrote: post #86
yokaze wrote: post #48

Earlier quoted context omitted.

China and Japan have Sunday as the first day since the 4th and 8th century respectively: http://chartsbin.com/view/41671 . So presumably, you come from a Europe-centric view: http://chartsbin.com/view/41671

China does? I'm Chinese and I'm pretty sure Chinese consider Monday to be the start.

Ah, sorry. Then I am misinformed. The locale "zh_CN" does give me Sunday as the first, which seems then misaligned with actual practice.

Re: ISO 8601: a better date format

#173

Post by twic »

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…

As of Java 8, the JDK also has support for ISO duration formats, via java.time.Period and java.time.Duration.

Re: ISO 8601: a better date format

#174

Post by Turing_Machine »

m_eiman wrote: post #29

While on the subject of time, could you Americans pretty please stop believing that the week starts on Sunday? It's just as wrong as your date format.

"Americans" didn't invent that idea.

The Hebrews did -- a long, long, long time ago.

Sunday is the first day of the week in almost all of the Americas, Japan, South Korea, and China.

Monday is the first day in Europe and some (relatively) recent European colonies (e.g., India).

The numbering of the days of the week is purely arbitrary. It makes no sense to claim that a particular ordering is "wrong".

If one goes by the sheer number of people who use a particular numbering, Americas + China comfortably exceeds Europe + recent European colonies.

Re: ISO 8601: a better date format

#175

Post by sirn »

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…

I think because it would defeat the portability of a timestamp because Asia/Tokyo isn't constant and you cannot lookup the offset without relying on external database that takes in ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in zoneinfo changes depending on day of a year, and sometimes even hour of a day, and the database of timezone is constantly updated (latest zoneinfo is version 2021a).

So while having 2021-02-26 18:38:00 Asia/Tokyo as a timestamp would more accurately represent the time, it would create another set of issues, namely requiring a database to look it up, and requiring to keep those database in sync in all systems in the world. Having both may be redundant because in that case you can't still trust the offset.

There are alternative systems such as TAI64[1] based on TAI[2] that are meant to accurately represent the moment in time without being subjected to leap second (only account them on conversion to UTC). The main issue is TAI64 is not really human readable (e.g. @4000000037c219bf2ef02e94) and would still require database of leap seconds to accurately convert back to UTC.

[1]: http://cr.yp.to/libtai/tai64.html

[2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time

Re: ISO 8601: a better date format

#176

Post by bhaak »

systemvoltage wrote: post #146
bhaak wrote: post #111

Earlier quoted context omitted.

This came up in a r/AskEurope thread and at least some slavic countries use decimeters. But that's the beauty about easily convertable units. Even if other people use other conventions, the mental process to convert them is almost zero. Just imagine somebody giving their height just in inches instead of the usual feet and inches? Could you mentally parse what 76 inches are? I guess you have basically no problem with…

Agreed, and needless to say, I use metric system at work (engineering). Now only if we evolved to have 12 fingers, we would have a supercharged metric system in duodecimal (base 12). Far superior to the decimal number system we use today. https://en.m.wikipedia.org/wiki/Duodecimal

Well, one of the oldest known systems was already very good. Alas, the Babylonian numeral system didn't completely make it down to us unfortunately.

Re: ISO 8601: a better date format

#177

Post by Andruru »

cm277 wrote: post #99
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…

I tried to push ISO to my (US/EU) company many times... it just doesnt work because you only need YYYY once in a while. Instead, we've settled on NATO formats (another US+EU org): 3 Nov 21 or just 3 Nov. It's unambiguous and short --yes, harder to parse and sort, but those are computer problems, always easier to solve than human problems...

"3 Nov" is ambiguous, it could mean 2020-11-03 or 2021-11-03, or any other year. And by the way, "3 Nov 21" is also ambiguous, it could be 2021-11-03 or 1921-11-03. Lots of stuff happened in 1921.

Re: ISO 8601: a better date format

#178

Post by Turing_Machine »

gherkinnn wrote: post #81
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.

What is a day in the solar system? What is anything anywhere anyway? That’s not the point. The point is that in the US people typically work Mon-Fri and loaf around Sat-Sun (weekend) and yet the week starts in Sundays. It’s infuriating.

A day corresponds to an actual rotation of the Earth, i.e., a day-night cycle.

A year corresponds to an actual revolution of the Earth about the Sun, i.e., seasons.

A week corresponds to...nothing. Four of them are a (very) rough estimate of the phases of the moon, but that's not something that really matters to anyone other than sailors nowadays.

Re: ISO 8601: a better date format

#179

Post by wongarsu »

SideburnsOfDoom wrote: post #55
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.

> I've never actually read the ISO 8601 spec, like probably most people here Indeed. The comprehensive Wikipedia article on ISO8601 is as far as we go https://en.wikipedia.org/wiki/ISO_8601 Thanks for pointing out rfc3339 - this appears to be the "useful part" of ISO8601 for data interchange. https://tools.ietf.org/html/rfc3339

Draft versions of the ISO standard are easy enough to find on the internet. But the Wikipedia article is excellent and covers just about everything.

Re: ISO 8601: a better date format

#180

Post by happymellon »

jacobolus wrote: post #49
vbezhenar wrote: post #13

Earlier quoted context omitted.

It took many decades to widely adopt UTF-8. I think that one of the reasons was that US companies did not really care about character encodings, as it's not something they have to often deal with. Even today managing multiple keyboard layouts is a pain in most operating systems, it's buggy, it does not have enough configuration options, it's not convenient. Probably because most US developers never tried to use that…

Mac Firefox and Mac Chrome both break a bunch of keyboard shortcuts if you use a non-US-ANSI keyboard. Safari handles alternate layouts correctly. Just yesterday I learned that on an ISO Spanish keyboard, both of those browsers will pop up a help menu for ⌘⇧7. The logic goes: ⇧7 means / on a Spanish ISO keyboard, and ⇧/ means ? on a US-ANSI keyboard, therefore ⌘⇧7 is by the transitive property of inter-layout shift f…

Mac everything breaks for me on a UK Mac when using an ISO keyboard rather than their non-standard ISO layout.

Page down only sometimes works, and Command+~ to switch same app Windows works in some apps and not others. It's a bit of a train wreck when you want to get rid of their pointless keys.

Post reply on HN