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

361–370 of 437 posts

Re: ISO 8601: a better date format

#361

Post by apricot »

kalleboo wrote: post #254
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…

> Not everything logical works with humans Works fine for the Chinese and Japanese, and last I checked they were humans. American English already has this weirdness elsewhere - the $-sign in $15 is read in the "wrong" place and always trips me up when I'm reading something out loud but others will defend that practice to the death

My ¢2: you are %100 right.

Re: ISO 8601: a better date format

#362

Post by [deleted] »

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.

[deleted]

Re: ISO 8601: a better date format

#363

Post by shpx »

andy-x wrote: post #277
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.

Only true if you ignore timezones and DST (which most people do because it is unholy mess) or stick to UTC.

or until you get into 5 digit years

Re: ISO 8601: a better date format

#364

Post by petee »

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.

I think it makes sense only in the fact that we write it how we say it out loud - "February 26th, 2021." It is just another convention, albeit inconvenient for computers. I doubt the british way of saying "26th of February" was done intentionally to aid sorting...

Re: ISO 8601: a better date format

#365

Post by apricot »

bhaak wrote: post #95
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…

I find it impressing that you can easily parse 20210226-00:01:25. The time is of course no problem but even with "20210226" standalone, I stumble and misread 10 and 22 before noticing that this doesn't parse. If there are more zeros and more 1's or 2's, it gets even worse. I hate it that the migrations in Rails are numbers only. "db/migrate/20210218125920_add_new_column.rb" is simply not human parseable.

When I visited China, I saw 11-digit phone numbers commonly written without any punctuation or spaces: like 12020569031. I guess you can get used to it.

Re: ISO 8601: a better date format

#366

Post by EdwardDiego »

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

Yeah I am a fan of ISO-8601 durations.

Re: ISO 8601: a better date format

#367

Post by wombatpm »

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…

Can we petition the government of Null Island (Lat 0, Long 0) to adopt the SaneLand defaults?

Re: ISO 8601: a better date format

#368

Post by marzell »

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.

This is my primary reason for advocating yyyy-mm-dd (regardless of including hh:mm:ss) in my work environment. I always feel it's very simple to explain things like "you can sort by name and it's automatically sorted by date" and it's just unbelievable the amount of pushback I get. This coming from users having trouble finding files from a certain time period, as their timestamps might be different due to copying/modifying. Also easy to convert to INT (i.e. yyyymmdd/20210226) for use as a partition key or FK for a date dimension.

Re: ISO 8601: a better date format

#370

Post by shpx »

aairey wrote: post #369
shpx wrote: post #363

Earlier quoted context omitted.

or until you get into 5 digit years

NMP. :D

It can be a problem/nuisance if you're working with nuclear waste or orbits.

It's also ironic how programmers are surprised by the passage of time when it's one of the only things that's truly guaranteed.

Post reply on HN