Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I also wish that the world would settle on a sane date-time format like the ISO 8601

IIRC, in most countries the native format is D-M-Y (with varying separators), but some Asian countries use Y-M-D. Since those formats are easy to distinguish, that's no problem. That's why Y-M-D is spreading in Europe for official or technical documents.

There's mainly one country which messes things up...



YYYY-MM-DD is also the official date format in Canada, though it's not officially enforced, so outside of government documents you end up seeing a bit of all three formats all over the place. I've always used ISO 8601 and no one bats an eye, and it's convenient since YYYY-DD-MM isn't really a thing, so it can't be confused for anything else, unlike the other two formats.


YMD has caught on, I think, because it allows for the numbers to be "in order" (not mixed-endian) while still having the month before the day which matches the practice for speaking dates in (at least) the US and Canada.


The primary reason for YMD is that DDMMYYYY is ambiguous with MMDDYYYY


It is also sortable, which I think is the real advantage.


I used to think this was really important, but what's the use case here?

If I'm writing a document for human consumption then why would I expect the dates to be sortable by a naive string sorting algorithm?

On the other hand, if it's data for computer consumption then just skip the complicated serialisation completely and dump the Unix timestamp as a decimal. Any modern data format would include the ability to label that as a timestamp data type. If you really want to be able to "read" the data file then just include another column with a human-formatted timestamp, but I can't imagine why in 2025 I would be manually reading through a data file like some ancient mathematician using a printed table of logarithms.


> If I'm writing a document for human consumption then why would I expect the dates to be sortable by a naive string sorting algorithm?

If you're naming a document for human consumption, having the files sorted by date easily without relying on modification date (which is changed by fixing a typo/etc...) is pretty neat


This is exactly it - file name is easy to control and sort on; creates date and modified date are (for most users) random and uncontrolled.


So you can't sort by name, author etc? One sort key? What year is it?!


As ling as you pad to two characters!


8601, when used fully according to spec sucks. It makes today 20250902. It doesn't have seperators. And for adding a time it gets even less readable.

Its a serialization and machine communication format. And that makes me sad. Because YYYY-MM-DD is a great format, without a good name.


YYYY-MM-DD is ISO8601 extended format, YYYYMMDD is ISO8601 basic format (section 5.2.1.1 of ISO8601:2000(E)[1]). Both are fully according to spec, and neither format takes precedence over the other.

[1] https://www.pvv.org/~nsaa/8601v2000.pdf


It does have a good name: RFC 3339. Unlike the ISO standard, that one mandates the "-" separators. Meanwhile it lets you substitute a space for the ugly "T" separator between date and time:

> NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.


I always like the compromise of the M/D/M system popularised by the British documentary series Look Around You, e.g. "January the fourth of March".


I live in that country, and I am constantly messing up date forms. My brain always goes yyyy-mm-dd. If I write it out, September 1st, 2025, I get it in the “right” order. But otherwise, especially if I’m tired, it’s always in a sortable format.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: