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

241–250 of 437 posts

Re: ISO 8601: a better date format

#241

Post by TeMPOraL »

MaxBarraclough wrote: post #222
timvisee wrote: post #220

Earlier quoted context omitted.

Yes! I constantly get complaints when using ISO 8601 on school documents. But I won't stop using it.

I guess the complaints are because the format is unfamiliar and strikes non-software people as being non-standard. Perhaps use a format like 3/Nov/2021 ?

That's missing the point of pressuring the other side to adopt ISO 8601.

(And in general case, of electronic documents with wider audience, using 3/Nov/2021 excludes people who don't know English (or the language in which you encoded the name of the month).)

Re: ISO 8601: a better date format

#242

Post by rswail »

bhaak wrote: post #111
systemvoltage wrote: post #90

Earlier quoted context omitted.

Not sure, I grew up in two countries, one metric and one english units. I still prefer inches and feet to describe length. I would like decimeter but no one uses it.

This came up in a r/AskEurope thread and at least some slavic countries use decimeters. But that's the beauty about easily convertable units. Even if other people use other conventions, the mental process to convert them is almost zero. Just imagine somebody giving their height just in inches instead of the usual feet and inches? Could you mentally parse what 76 inches are? I guess you have basically no problem with…

English/Australian people used to (still do?) measure their weight in stones and pounds. The average man was "13 stone" which is 182 pounds.

US people measure their weight in pounds, 182lb

So yes, a USian telling their weight to a UKian would be like saying their height in inches.

Re: ISO 8601: a better date format

#243

Post by rswail »

pimlottc wrote: post #52
systemvoltage wrote: post #28

No one here is talking about practicality for non-software engineers which is probably 99.9% of the population. It might be fine for sorting and no one gives a shit about endianess. Common person would argue - why do they need to know the year first? Most people encounter dates in the same year, they already know we're in 2021 and it is not as important. Having to laboriously parse YYYY before getting to the most imp…

The alternate I like to use on forms and such when I know it's likely going to be read by a human is "DD Mon YYYY", e.g. 1 Feb 2021 This is a bit more human-readable and closer to commonly-used forms of dates while still being completely unambiguous.

I worked on a system once that failed in Sweden when we changed the locale from US.

Someone was getting the date as 01MMMYYYY and using it as a partition name. When the first day of the tenth month happened, everything broke, because it was expecting OCT, not OKT.

Unambiguous but wrong.

With humans reading it, either you need to be unambiguous, so use yyyy-mm-dd, or you don't have to be, so use a format that most of your audience will understand.

Re: ISO 8601: a better date format

#244

Post by brnrr »

Here's an interesting date format most of HN probably haven't heard of; military date-time-groups[1].

  270009LFEB21
Translation: The 27th, 00:09, "L" timezone (+11, NATO timezone[2]), February, 2021.

Advantages:

- it's much more compact than ISO8601.

- the most significant information is first; the date.

- the second-most significant information is second; the time.

- the timezone is a single alphanumeric character.

- when military paperwork has a box at the top that says "DTG", everyone knows the format.

- I'm pretty sure it's a standard across all NATO militaries.

[1] https://en.wikipedia.org/wiki/Date-time_group#Military_Date_...

[2] https://en.wikipedia.org/wiki/List_of_military_time_zones

Re: ISO 8601: a better date format

#245

Post by rswail »

akavel wrote: post #44
grenoire wrote: post #11

Earlier quoted context omitted.

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

You can specify an interval as start/duration, start/end, or duration/end.

So you could specify a negative offset as a duration and the end time.

P2H/2021-02-26T13:30Z is two hours prior or T11:30Z on the same date.

Re: ISO 8601: a better date format

#246

Post by rswail »

Turing_Machine wrote: post #186
FooBarWidget wrote: post #86

Earlier quoted context omitted.

China does? I'm Chinese and I'm pretty sure Chinese consider Monday to be the start.

Not according to: https://unicode-org.github.io/cldr-staging/charts/38/supplem... Note that common usage and the official definition may well differ. Most Americans probably consider Monday the "first day of the week" as it is the first day in a standard work week. But officially , Sunday is the first day of the week.

Which is weird, because "god rested on the seventh day" and the Christian religion believes that to be Sunday, so it is the last day of the week.

Why does the US think that the week starts on Sunday?

Re: ISO 8601: a better date format

#247

Post by taylodl »

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.

Every time there's a discussion on date/time formatting I always refer people to RFC 3339 (https://www.ietf.org/rfc/rfc3339.txt).

Learn it, live it, love it!

Re: ISO 8601: a better date format

#248

Post by cesarb »

TeMPOraL wrote: post #116
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…

Yup. I hate // AM/PM formats with a passion. Doesn't help that I work with UK teams now, and their "natural" date format is 3/11/2021, with meaning of 3 and 11 reversed to what they'd mean for Americans... sigh . ISO 8601 everything. I'm religious about it. I write it in messages, on government forms, anything that doesn't force me to use a different format. On a bit of my insistence, we use ISO 8601 notation for all…

> ISO 8601 everything. [...] on government forms

On government forms (and other paper forms), I use 3/11/2021. It's unambiguous; nobody would expect it to mean anything other than "3rd of November of 2021". The ambiguity only happens once you add the Internet to the mix, and even then, only in English-language websites (I wouldn't expect anything other than DD/MM/YYYY on Portuguese-language websites, and the same probably applies to most other languages).

Re: ISO 8601: a better date format

#249

Post by orwin »

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.

My great great grandfather wrote a book about this 120 years ago! And yes, it was for taxes and accounting.

Re: ISO 8601: a better date format

#250

Post by Markoff »

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, it's quite easy for sorting actually since H never follows C in Slovak or Czech language and when they are together they always make letter CH, so it should be easy to fix for sorting file/folder names

orally we use 12 hours time format even in most of the Europe, we just use in digital watch 24hr format

Post reply on HN