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

381–390 of 437 posts

Re: ISO 8601: a better date format

#381

Post by TeMPOraL »

andy_ppp wrote: post #315
alexvoda wrote: post #239

Earlier quoted context omitted.

That's why we have international standards. So that 1 version of right and all others are wrong. And no matter how arrogant it might seem, at least for computing use cases, ISO 8601 is right and other date formats are wrong. There are absolutely no usecases where the US date format makes sense. No, having it written in the order you prefer to pronounce it is not an argument. Especially not in the language where you h…

I don’t disagree, in an ideal world great, let’s get everyone to change to ISO8601. I’m a big fan. However until developers become in charge of all the decisions (imagine!) I’ve suggested a reasonable solution that most people can use to format dates in 99% of users locales with too much hassle. There are more interesting bridges to die on.

> However until developers become in charge of all the decisions (imagine!)

The thing is, we sort of are! As I mentioned upthread, notation and language are being strongly influenced by increased use of software in every facet of our lives. The way people note numbers, dates, express search terms, etc. are all impacted by what the software accepts and displays by default. We have an opportunity here to push for positive cultural change around international standardization, so let's make good use of it, instead of squandering it by just implementing whatever seems to resemble the local status quo the most.

Re: ISO 8601: a better date format

#382

Post by gr__or »

> a lesser-known date format called ISO 8601

is he being ironic? One of the things I love most about 8601 is it being supported by basically every* std lib (and definitely every library working with dates)

* JS, Python, Ruby, PostgreSQL,...

Re: ISO 8601: a better date format

#383

Post by toast0 »

frn123 wrote: post #353
bombcar wrote: post #208

Earlier quoted context omitted.

It’s a representation of how us Americans talk - we rarely say 26th of February and instead say February 26 - and if necessary tack on the year. It feels exceptionally awkward to say 26 February, thought saying “twenty twenty one February 26” sounds very strange, too. But people are very good at verbally saying different than is written.

No native speaker but isn't 4th of July more common than July 4th?

The Fourth of July and Cinco de Mayo are exceptional days.

Tax day is the ides of April, but we just say April 15th.

Re: ISO 8601: a better date format

#384

Post by Viliam1234 »

Markoff wrote: post #250
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.

that's reason I switched to ISO 8601 in my folders structure decades ago, obviously can't use it in regular documents/communication in Europe there used to be similar problem with alphabet (folder) sorting though, where Windows used to sort letter CH which goes after H in alphabet right within C as if CH didn't exist, but I think they sorted it in recent years, though I use English Windows and still have this issue,…

> H never follows C in Slovak or Czech language

"viachodinový" (multihour), "viachlavý" (multiheaded)... in Slovak. Not sure if there are examples in Czech.

Essentially, in Slovak it is impossible to implement algorithmical alphabetical sorting without understanding the language, to determine whether "ch" appears on the word stem boundary. But yeah, you can sort 99.99% of words by assuming it does not... and maybe increase it to 99.9999% by making an exception for words starting with "viac-".

Re: ISO 8601: a better date format

#385

Post by boring_twenties »

mywittyname wrote: post #358
boring_twenties wrote: post #350

Earlier quoted context omitted.

What's the problem with strtoul? Just make sure to pass 10 as the third parameter, not 0.

Maybe the punishment in hell should be to RTFM for the rest of eternity.

Sorry, what?

It's not like it's a default parameter, you would have to explicitly pass zero if you want the "guess base based on prefix" behavior.

Re: ISO 8601: a better date format

#386

Post by wiml »

btilly wrote: post #346
koolba wrote: post #302

Earlier quoted context omitted.

There's a special place in hell for people that using variable length representations for time units that are meant to be consumed by machines. I think it's across the hall from the room for people who configure servers for anything besides UTC.

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.

Re: ISO 8601: a better date format

#387

Post by saithound »

akalsz wrote: post #256
saithound wrote: post #118

Earlier quoted context omitted.

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…

I believe that these conventions (at least for dates) are indeed the most practical for their respective languages. Take for example "October the third, two thousand nine" (10/3/2009, MDY). In German one would pronounce this as "der dritte Oktober zweitausendneun" (3.10.2009, DMY). In Hungarian "kétezer-kilenc október harmadika" (2009. 10. 03., YMD). All of these pronunciations reflect the order numerical dates are w…

Certain orders are grammatically more convenient in certain languages, but that's not the same sense of practical as the one referenced above: cf. "inches are more practical than meters because they have the same spelling in American and British English", vs. "inches are more practical than meters because they're human-scale units".

Sure, date order may be decided based on accidental grammatical features of the target language. But that just reaffirms that "practicality for the common man" is rationalization.

Naturally, the written convention need not affect pronunciation: in the case of numbers, the world standardized on decimals with place values increasing from right to left, but most languages retain their own idiosyncratic ways of naming/reading them This causes negligible friction in practice.

Re: ISO 8601: a better date format

#388

Post by hda2 »

superzamp wrote: post #347
sebmellen wrote: post #105

Earlier quoted context omitted.

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

And the way if forces you into a full-blown file search when you start typing letters and are just looking for files with that prefix...

I open a new terminal and tab my way to the file I want because it's quicker and less mentally-demanding than solving Gnome's UI puzzles. At least I used to until I had enough and switched to a different file manager.

Re: ISO 8601: a better date format

#389

Post by hda2 »

cheph wrote: post #191
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…

XFCE allows you to set a strftime string for date format.

I'm fairly certain that GNOME2 used to as well.

Re: ISO 8601: a better date format

#390

Post by matheusmoreira »

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?

Post reply on HN