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

201–210 of 437 posts

Re: ISO 8601: a better date format

#201

Post by andy_ppp »

jiggawatts wrote: post #192
andy_ppp wrote: post #132

Earlier quoted context omitted.

Format the date on the frontend using date.toLocaleDateString() and let the browsers locale do the work for you (assuming you’re in JS and on the web).

Short of stepping through the JavaScript line-by-line, how do you tell the difference between these two dates? 3/11/2021 3/11/2021 The difference is one was formatted incorrectly, and the other was formatted correctly. One is 2021-03-11, the other is 2021-11-03. Even having been told that there's a difference, you cannot know which is which. Even if you think you know because you found an unambigious date like 31/11/…

You're making the assumption that users know YYYY-MM-DD is the date format and not YYYY-DD-MM. I bet if you asked non-developers the answers you would get would be pretty random, probably more errors than the locale on their machine.

Re: ISO 8601: a better date format

#202

Post by simon04 »

Has anyone succeeded in configuring GNU/Linux to consistently output dates in ISO 8601 format? A partial solution involves...

  ls -l --time-style=full-iso
  git log --date=iso
  date --iso-8601=s # or date --rfc-3339=s
  export TIME_STYLE='long-iso'

Re: ISO 8601: a better date format

#203

Post by HenryBemis »

jiggawatts wrote: post #6

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…

On presentations for projects I tend to add a couple of 'fun' slides. When said projects involve people in the USA, I (almost always) include the XKCD ISO 8601 cartoon:

https://xkcd.com/1179/

It is one of my favourites (the "8601", the "Security", and the "Bobby Tables")

Re: ISO 8601: a better date format

#204

Post by samwhiteUK »

jiggawatts wrote: post #6

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…

This is mentioned in the article....

Re: ISO 8601: a better date format

#206

Post by bombcar »

majewsky wrote: post #170
SwiftyBug wrote: post #158

Earlier quoted context omitted.

My wife recently bought by mistake a keyboard whose layout I couldn't figure out. It took me a full 5 minutes to even get to the correct place where I could configure keyboard layouts under Windows 10 settings. Then I had to choose the keyboard layout I wanted to add. This was a list in a dropdown with hundreds of options without an image of what each layout looks like so I could not check which option matched the ke…

I like the method that Mac OS uses to detect the layout of a newly connected keyboard. It brings up a dialog asking the user to press specific keys (something like "type the | character") until there is only one possible layout that would generate the observed keycodes for the characters in question.

It’s really well done - and usually Identifies the most common keyboards in only a few key presses.

Re: ISO 8601: a better date format

#207

Post by parhamn »

BoppreH wrote: post #184
sirn wrote: post #175

Earlier quoted context omitted.

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…

I knew about TAI but TAI64 is new to me, thanks. About the TZ database, don't all date lookups require accessing it? If I schedule a meeting in Asia/Tokyo now, and the database tells me it's +09:00, I still have to remember it's Asia/Tokyo because the offset may change 5 minutes before the meeting. Analyzing the timestamp requires a TZ database, but that's calendars for you; the encoding is not going to change this.…

Most of the time you’d just need their current timezone offset (not location) to convert the stored offset into, no?

Re: ISO 8601: a better date format

#208

Post by bombcar »

lostlogin wrote: post #147
knorker wrote: post #120

Earlier quoted context omitted.

Sure you can tell. You just hire an investigator to find out who wrote the memo, and find where in the world they grew up, in what culture. If the answer comes back very US, then it's middle endian US format. Else it's DMY. Note that the article is wrong to just say "dd.mm.yy" is used in "Europe". Some countries use yyyy-mm-dd and others dd/mm/yy. The US format is the only one that's retarded, though.

> The US format is the only one that's retarded, though. I wonder how it started? A skim of the internets hasn’t enlightened me.

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.

Re: ISO 8601: a better date format

#209

Post by sirn »

BoppreH wrote: post #184
sirn wrote: post #175

Earlier quoted context omitted.

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…

I knew about TAI but TAI64 is new to me, thanks. About the TZ database, don't all date lookups require accessing it? If I schedule a meeting in Asia/Tokyo now, and the database tells me it's +09:00, I still have to remember it's Asia/Tokyo because the offset may change 5 minutes before the meeting. Analyzing the timestamp requires a TZ database, but that's calendars for you; the encoding is not going to change this.…

I think the main usage of ISO 8601 was to represent a point in time in UTC for exchange, not a local time plus timezone. When a date such as 2021-02-26 18:38:00+0900 is provided, it did not meant 2021-02-26 18:38:00 in Asia/Tokyo, but meant 2021-02-26 09:38:00 in UTC. e.g., 09:38:00Z and 18:38:00+0900 and 16:38:00+0700 were supposed to be equivalent.

In this case, timezone is external to this format and the timestamp can be calculate back to UTC without relying on zoneinfo (which is very useful for exchange). Any further conversation would be external to this format. e.g., in case of calendar, it's probably more useful to have datetime in local timezone rather than of the other party's timezone so the tuple would be (utc_time, local_tz) rather than (other_localtime, other_tz, local_tz).

Re: ISO 8601: a better date format

#210

Post by bombcar »

smcl wrote: post #200
slazaro wrote: post #166

Earlier quoted context omitted.

How about french? 99 is four twenties nineteen, 79 is sixty nineteen. Languages are fun and fascinating.

I think your response to these language quirks can vary depending on your familiarity with the language: - to an outsider, learning that a concept exists: “that is an interesting thing” - to a beginner, trying to construct the right form or to detect it in quickly spoken speech: “this is annoying and I hate it” - to an intermediate speaker and beyond: “eh it’s maybe weird but whatever” I used to hate noun declension…

I’ve always thought it’s interesting how the languages like that (most of the Romance languages have declensions and such) add error detection and even correction - you can figure out parts that are missing or got changed by the lack of agreement between the various forms.

You may not be able to correct it from the Information available but you’ll know something went wrong.

Post reply on HN