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

301–310 of 437 posts

Re: ISO 8601: a better date format

#301

Post by 908B64B197 »

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.

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.

Re: ISO 8601: a better date format

#302

Post by koolba »

pwg wrote: post #295
jeff-davis wrote: post #286

Earlier quoted context omitted.

Lexicographic sorting does not work for numbers of different lengths, e.g. "100" and "9".

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.

Re: ISO 8601: a better date format

#303

Post by mjevans »

eurasiantiger wrote: post #65
mjevans wrote: post #19

Earlier quoted context omitted.

I loath the T and Z characters, so respectively I use a single dash (Between the date and time) and no Z; for time I often leave in the colons (:). Example: 20210226-00:01:25 this presents the data in a format I can easily visually parse and also easily search for useful things in log files with. When parsing such a date I tend to throw out all of the characters, but the 'Zulu' or timezone at the end probably should…

In other words, you are not using a standard format.

I think of it as a modified form of the standard format, where the standard format doesn't fulfill the needs of my use case.

Re: ISO 8601: a better date format

#304

Post by JdeBP »

globular-toast wrote: post #193
gherkinnn wrote: post #81

Earlier quoted context omitted.

What is a day in the solar system? What is anything anywhere anyway? That’s not the point. The point is that in the US people typically work Mon-Fri and loaf around Sat-Sun (weekend) and yet the week starts in Sundays. It’s infuriating.

What practical difference does it make to you? The week starts whenever you decide it starts. Would it annoy you even more if I decided to start my week on Thursday?

It used to be common for the academic week to begin at noon on Wednesday. So that's not as unlikely an idea as one might think.

Re: ISO 8601: a better date format

#306

Post by heipei »

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…

I don't know, I'm German and deal with US folks a lot, for me it's like this: Date written with slashes or dashes (3/11/2021 or 3-11-2021) implies US-based month/day/year. Date written with dashes and the year first and zero-padding (2021-03-11) implies year-month-day, aka ISO8601. Date written with dots and without padding (11.3.2021) implies my native format, day.month.year.

Re: ISO 8601: a better date format

#307

Post by JdeBP »

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.

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

Re: ISO 8601: a better date format

#308

Post by kube-system »

CuriousNinja wrote: post #234
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.

> never actually read the ISO 8601 spec ... because it's not free I was very surprised to discover this. Why are they charging money for the specification of a date format? I would expect standards like these to be published in public domain.

ISO finances their operations by selling documentation, subscription from members, etc. The point of ISO standards is to facilitate international trade. The intended audience for these standards are large multinational companies.

Re: ISO 8601: a better date format

#309

Post by exporectomy »

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…

It doesn't help at all if they try to localize it because then it's just 11/3/2021 which is equally confusing and you have no idea if they're using your local format or theirs. Any what's your local format? The country you're in or the country you were in when you signed up for the service or the country your VPN server is in? Internet services really need to stop using these stupid mistake-inducing, time wasting date formats. People might have a sense of unfamiliarity seeing ISO8601 format but they can still understand it.

I use ISO8601 dates everywhere possible. Paper forms in the real world where people look at me strangely, invoices, file names which is really handy for sorting, my personal todo lists, everything.

Post reply on HN