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

341–350 of 437 posts

Re: ISO 8601: a better date format

#341

Post by trinix912 »

globular-toast wrote: post #34

The US format is indeed awful but so is the European one really. ISO-8601 is the only one that makes sense, although the concept of months isn't really useful at all. But it's not always unambiguous. ISO-8601 supports local time. It's only an unambiguous timestamp of the time zone is included.

> The US format is indeed awful but so is the European one really

There are many different European formats, some countries even use (a slightly modified version of) ISO-8601, ex. in the Nordics.

Re: ISO 8601: a better date format

#342

Post by davidbanham »

A note from the front line. I actually use 8601 dates in a date-heavy consumer product ( https://clubman.app ) and it’s hands down the feature I most consistently get user feedback on.

It’s always “Why are the dates all American format? Can you change them to English?” And then I try to patiently explain that they’re actually international format.

People seem to have internalised that any date format they find slightly unfamiliar is “the bad American one”

I’m in the process of cutting everything I can over to “24th Jan 2020” style.

Re: ISO 8601: a better date format

#343

Post by emj »

emergie wrote: post #313
908B64B197 wrote: post #301

Earlier quoted context omitted.

The standard American date format (MM/dd/yyyy) also somewhat has this property for a limited number of use cases. Sorting within a single year will work, sorting multiple years will place the same date adjacent to each other so it makes them easy to compare if you are printing out let's say sales data.

Americans using cal/foot/elbow/galon system of measurements is quirky, but bearable. AM/PM thing is silly, but bearable. Malformed MM[/-.]dd[/-.]yyyy date format is one of the most confusing thing I have ever encountered and it generates serious problems.

> it generates serious problems

I would say that by just existing it create serious problems. You can never be sure if a date if day/month or month/day, this was especially bad from year 01 to 12. During those twelve years I was a date zealot "there can be only ISO 8601".

Re: ISO 8601: a better date format

#344

Post by happymellon »

PeterisP wrote: post #292
happymellon wrote: post #185

Earlier quoted context omitted.

That is horrifying. I am glad I have never met these people.

yyyy.dd.mm. (but not with hyphens!) are commonly used for all the languages where their grammar and word order means that the spoken way to say dates is like "twothousandtwentieth year's first march".

eye_twitch.gif

Re: ISO 8601: a better date format

#345

Post by p_l »

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

If document didn't have specified time format, I never had issues using YYYY-mm-dd from ISO 8601. And the ones that had specified time format were upfront about expected format, so...

Would be interested where anyone encountered issues with ISO8601 dates

Re: ISO 8601: a better date format

#346

Post by btilly »

koolba wrote: post #302
pwg wrote: post #295

Earlier quoted context omitted.

It does if you zero fill the shorter number to an equal number of digits: "100", "009".

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?

Re: ISO 8601: a better date format

#347

Post by superzamp »

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.

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

Re: ISO 8601: a better date format

#348

Post by nemetroid »

rswail wrote: post #240
AlanYx wrote: post #197

Earlier quoted context omitted.

The "week date" format (yyyy-www-d) in ISO8601 is IMHO why it's usually better to refer to RFC3339, which doesn't allow the week date format. So many people are unaware that the ISO8601 format allows "week date" and/or don't understand its quirks, and articles like this one, which don't even mention that ISO8601 dates can appear in this format, compound the problem.

What about the Durations and Intervals? The "Week" format is great for planning purposes, because it allows a granularity between days and months with another whole number per year. Saying that a task will begin 2021-W08 and then defining the start of the week (ISO8601 says its a Monday), tells you exactly when it will start. Saying the task is 2021-W08/P4D tells you exactly when it starts and how long it will take.…

Week numbering introduces confusion when interacting with countries like the U.S. where weeks aren't considered to start on Mondays.

Re: ISO 8601: a better date format

#349

Post by CyberRabbi »

maxwell wrote: post #294
CyberRabbi wrote: post #276

Earlier quoted context omitted.

> Why would that matter? Arguably the ideal lingua franca should have no native speakers at all as those have an unfair advantage. I share your vision of an explicitly taught universal language which gives no group or individual an unfair advantage. We obviously need more equality in the world. From the perspective of trying to maximize how many people with whom you are able to communicate, however, on a practical ba…

Your numbers above list 1.132B English speakers and 1.116B Mandarin speakers.

A larger percentage of mandarin speakers are native mandarin speakers than the equivalent statistic for English. 918 million native mandarin speakers, 310 million native English speakers. Native speakers are generally better at understand the nuances of language than non-native speakers.

Re: ISO 8601: a better date format

#350

Post by boring_twenties »

JdeBP wrote: post #307
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.

Is their punishment to be forced to parse "009" with the C language's strtoul() library function for all eternity? (-:

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