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

391–400 of 437 posts

Re: ISO 8601: a better date format

#391

Post by hilbert42 »

tpetry wrote: 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.

"your filesystem will automatically sort files correctly if you prefix them with a iso 8601 date."

It's the default date format on my PCs, I've used it for decades. I find it hard to understand why eveyone doesn't use it.

Also, if you work for the UN, it's the default date format.

Re: ISO 8601: a better date format

#392

Post by matheusmoreira »

sebmellen wrote: post #105
young_unixer wrote: post #94

Tangentially related: I hate GNOME's approach at configuring formats. In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system. Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator. You can have sane dat…

This is one of my biggest gripes with GNOME, along with the incredibly stupid lack of thumbnails in the file browser.

That still hasn't been fixed? It's been so long it's become an old meme at this point. People still mock Linux for it...

Re: ISO 8601: a better date format

#393

Post by btilly »

wiml wrote: post #386
btilly wrote: post #346

Earlier quoted context omitted.

Where do you put the people who think that we should inflict leap seconds on UTC?

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 possibility of leap seconds.

All for something that, over thousands of years, won't lead to as big a discrepancy between the Sun and the clock as what we voluntarily do 2x per year for daylight savings time.

Does it make any sense to continue this insanity? Why?

Re: ISO 8601: a better date format

#394

Post by SAI_Peregrinus »

young_unixer wrote: post #94

Tangentially related: I hate GNOME's approach at configuring formats. In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system. Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator. You can have sane dat…

I don't use GNOME, so I can't say exactly how it configures those formats, but from the rest of the discussion it seems to just set the locale, probably via LC_ALL. But you can set the various settings individually.

Sane Linux Locale settings

    LANG="en_US.UTF-8"  
    LANGUAGE="en_US"  
    LC_CTYPE="en_US.UTF-8"  
    LC_NUMERIC="en_US.UTF-8"  
    LC_TIME="en_CA.UTF-8"  
    LC_COLLATE="en_US.UTF-8"  
    LC_MONETARY="en_US.UTF-8"  
    LC_MESSAGES="en_US.UTF-8"  
    LC_PAPER="en_US.UTF-8"  
    LC_NAME="en_US.UTF-8"  
    LC_ADDRESS="en_US.UTF-8"  
    LC_TELEPHONE="en_US.UTF-8"  
    LC_MEASUREMENT="en_DK.UTF-8"  
    LC_IDENTIFICATION="en_US.UTF-8"  
    LC_ALL=
On my Debian system (KDE) that works for what you asked for. LC_MEASUREMENT="en_DK.UTF-8" sets SI units, LC_NUMERIC="en_US.UTF-8" sets dot as decimal separator, and LC_TIME="en_CA.UTF-8" sets ISO 8601 dates and times with 24H format. LC_ALL being left undefined is important, it will override the rest.

The process for updating your locales will vary depending on your distro. But even if GNOME doesn't allow it you should be able to use the terminal.

Re: ISO 8601: a better date format

#395

Post by SAI_Peregrinus »

akvadrako wrote: post #229
Symbiote wrote: post #225

Earlier quoted context omitted.

That reflects (supposedly) the official standard, but even on government forms DD-MM-YYYY or DD.MM.YYYY is used. I have never seen the ISO format used outside computer systems, unlike in Sweden where it's commonplace. It's inconsistent with da_DK, which uses DD-MM-YYYY. But there's already the decimal separator bug (writing English? dot, writing Danish? comma). % en_DK is used outside Denmark, as some sort of generic…

Right, en_DK has almost nothing to do with Denmark, instead it's basically the imaginary Saneland the top poster asked for. I agree en_EU would make more sense, maybe somebody should submit a patch to glibc and in a decade it'll be safe to switch.

You can mix and match. Unset LC_ALL, and set the following: LC_MEASUREMENT="en_DK.UTF-8" sets SI units, LC_NUMERIC="en_US.UTF-8" sets dot as decimal separator, and LC_TIME="en_CA.UTF-8" sets ISO 8601 dates and times with 24H format.

But there should definitely be a saneland locale. "en_SANE.UTF-8".

Re: ISO 8601: a better date format

#396

Post by nayuki »

notatoad wrote: post #331
PowerBar wrote: post #189

Earlier quoted context omitted.

Canada is even worse, we can't decide which one to use so you never know what format it's in. I was once sent paperwork to fill out that had dates requested in both MM/DD/YYYY and DD/MM/YYYY formats on different pages.

the upside of Canada's incredibly stupid date formats is that nobody complains when you try to use ISO8601 format instead, we're all somewhat used to date formatting being flexible. My american users get very angry when they see a date that isn't in dd/mm/yy format.

Corrections: Most but not all government forms in Canada use yyyy-mm-dd format, which is a positive change. But indeed we are used to living in a mishmash of American, European, and ISO influences. Americans might get angry if you don't use mm/dd/yy format; I'm not aware of them being attached to dd/mm/yy.

Re: ISO 8601: a better date format

#397

Post by nayuki »

mjevans wrote: post #26
kitd wrote: post #2

The real purpose of endianness which is missed here is the ability to sort. Sorting a list of iso8601 dates alphabetically means sorting them chronologically too.

That's also the only time (full) European dates make sense, when writing them on the right hand side of a ledger page so that the exterior of the ledger / book is indexed with the largest components on the edge of the page. US dates only make sense if you don't care about the year and are writing on the left most side of a page; that might make sense if ink or paper is at a premium.

What you said about European dates (e.g. 27/02/2021 today) is not strictly true. The rightmost character is the ones digit of the year, and it is not the largest component. According to your rules, 01/01/2019 would be "larger" than 01/01/2021 because 9 is larger than 1.

The blog post already made this observation, saying that YMD is the only format where the endianness of the date components match the endianness of the numbers; DMY does not have this property. If you wanted to sort dates correctly on the right hand side, you need to write the numbers backwards too, like "72/20/1202".

Re: ISO 8601: a better date format

#398

Post by sixothree »

marzell wrote: post #368
tpetry wrote: 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.

This is my primary reason for advocating yyyy-mm-dd (regardless of including hh:mm:ss) in my work environment. I always feel it's very simple to explain things like "you can sort by name and it's automatically sorted by date" and it's just unbelievable the amount of pushback I get. This coming from users having trouble finding files from a certain time period, as their timestamps might be different due to copying/mod…

Same here. Even when it's just a folder with a document that has multiple revisions. And especially around this time of year (near the end/beginning of the year).

Re: ISO 8601: a better date format

#399

Post by sixothree »

jeff-davis wrote: post #286
m12k wrote: post #42

Earlier quoted context omitted.

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.

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.

Re: ISO 8601: a better date format

#400

Post by nayuki »

FooBarWidget wrote: post #63

Coming from China, western date and time formats puzzle me. In China we use the ISO 8601 order for dates. Because of this, and also for all the reasons stated in the article, I use the ISO 8601 format in all my software. As a user, it really bugs me when an app uses either the European or the US format, but doesn't tell me which one it is.

China's date format isn't as good as ISO 8601. Let's ignore the 3 Chinese characters (年月日) for a moment. The problem is that the Chinese format does not use leading zero padding - e.g. 2021年5月8日 - which makes the format variable-length and much harder to sort.
Post reply on HN