Live data from Hacker News

ISO 8601: a better date format

kirby.kevinson.org

41–50 of 437 posts

Re: ISO 8601: a better date format

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

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

Re: ISO 8601: a better date format

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

Which is a side effect of being consistent with the way we write all other numbers, with the value represented by each digit declining as we go left to right.

Re: ISO 8601: a better date format

#43
post #16
post #5

Earlier quoted context omitted.

Until we hit year 10000, but yeah, that's still a looong time to go.

There's some proposal that this year 2021 is actually 12021, to make the year neutral of some specific religious event.

I know you’re not saying you are encouraging it and it’s just a related but of trivia, but I find that hilarious. Because when someone asks “why start there?” the answer “it’s a thousand years before Jesus Christ was born, the millennium heralding his arrival” is better?

(I’m not even Christian but I also don’t have a chip on my shoulder and can accept its influence on the world)

Re: ISO 8601: a better date format

#44
post #7

yyyy-mm-dd is so nice you can just work with strings for your date stuff, converting to objects and back is tedious Shameless plug: I built a python library to do exactly that https://pypi.org/project/yyyy-mm-dd/

Quite nifty and clean; I think this could play well with support for the duration (P-Y-M-D...) format in ISO 8601 that declares a positive offset. https://en.wikipedia.org/wiki/ISO_8601#Durations

Interesting, didn't know about that! Do you know of some canonical way of expressing negative offsets in spirit of ISO 8601? I don't seem to see those mentioned in the article...

Re: ISO 8601: a better date format

#45

The unmentioned benefits: it is fixed-width and follows most to least significant parts left-to-right. What this means is that the significance of the parts follows the same L-R convention as numbers, making it intuitively obvious which is the month and which is the day. Oh, and a simple string sort will sort timestamps correctly - very handy at the command line. Even db columns holding timestamps as strings will get…

Both of these points are mentioned in the article.

Re: ISO 8601: a better date format

#46
post #9

There's another aspect you may not know about: It's close to how it's done in chinese, which is 2021年3月17日. They use different separators (the chinese words for year, month and day), but it's close enough. Given that china is the country with the largest population it may not be a bad idea to use something a large number of people will easily understand.

Maybe we should also start speaking Chinese since it may not be a bad idea to use something a large number of people will easily understand. Edit: this is not sarcasm. It’s simple logic, unless there is something wrong with learning other languages.

Maybe we should sterilize a neighborhood muslim to familiarise ourselves with their practises and later we can bond over it. (Biden recently said it's none of our business but that's just ice-cold)

Re: ISO 8601: a better date format

#47
post #7

yyyy-mm-dd is so nice you can just work with strings for your date stuff, converting to objects and back is tedious Shameless plug: I built a python library to do exactly that https://pypi.org/project/yyyy-mm-dd/

It's not tedious if you do it right. All of your conversions should be done in your I/O layer and nowhere else. For many applications that means there's a single place to do it. Hardly tedious.

I notice that your library is targeted at notebooks, though. It seems useful in that context, but not for general programming.

Re: ISO 8601: a better date format

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

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

Re: ISO 8601: a better date format

#49

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 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 functions equivalent to ⌘?, which is the shortcut for opening the help menu.

They don't pop open the help menu if you press ⌘⇧', the actual ISO Spanish layout way to type ⌘?

Re: ISO 8601: a better date format

#50

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

And multiple languages. Spell-chackers enabled by default are specially annoying.
Post reply on HN