yes, YYYY-MM-DD HH:MM:SS is the only proper format.

It is sorted from the greatest unit (year) to the smallest unit (second). If you treat them as text and sort alphabetically they still get sorted from oldest to newest.

Other formats don't sort properly.

writing dd.mm.yyyy is like writing time ss:mm:hh

writing mm/dd/yyyy is like writing time mm/ss/hh

If I really have to put YYYY at the end of the date I use the 'dd-mmm-yyyy' format which excel translates based on client locale:

- 13-mar-2020 in enUS

- 13-bře-2020 in czech

I agree with everything you are saying about sorting and I frequently use YYYY-MM-DD, however I do want to make one point: DD.MM.YYYY does make some human sense as a date format since the year is very rarely important (and if the year is actually important often the day is so unimportant that it can be left out), the month is sometimes important and the day is often the most relevant piece of information.

So for any kind of practical planning that day first order makes some sense, but I wouldn’t die on a hill for it.

I see where you are coming from, but I would argue that if you omit a part, it's not a date anymore.

Yes! It's not the first time I posted a rant on the net and found myself guilty of the sin the very next day. This time, a web app of mine has big tables full of dates, and I didn't quickly figure out a way to show the full date without too much clutter. So, I used "dd.mm" and postponed a finer design till next year. Guess what, this UI element hasn't changed in the next three years and today I finally stumbled on a bunch of records which really can't be deduced from context.

It’s a cultural thing: if I’m not mistaken the traditional Chinese system is Y-M-D and always has been.

I suggest a literal T instead of a space, and don’t forget the timezone offset (or a literal Z).

ISO 8601 is great.

I agree with and independently also use the parent's modification to ISO8601 with that respect; though I do frequently call the format string that contains whatever magic cookies get that output something similar to iso8601mod. (The modifications: Emit a string rather than a T, and (if included) use the email like +/-OFFSET to indicate the current timezone offset rather than specify a timezone. No offset implies UTC for system times and local time for human-facing times.)

Well it is but the T is ugly :/

I would argue that its use goes beyond sorting and includes people making mental estimates about time intervals. Having some sort of sensible order helps here, which I'm guessing is YMD for left to right languages and DMY for right to left languages, since that puts the most significant digits first.

No, it does not take into account timezones.

We have ISO 8601, no need to reinvent the wheel as a square.

https://xkcd.com/1179/ (date only)

This XKCD is incorrect, 20130227 is also a valid ISO 8601 date.

agreed fully

How is "06.08.2020" unambiguous?

There are no conventions that write a date as mm.dd.yyyy, so if you encounter a date in that format, it is safe to assume dd.mm.yyyy.

Contrast this with the slash or dash notation, where both mm/dd/yyyy and dd/mm/yyyy are prevalent in the world. But 2020-08-06 is unambiguous in the same way that 06.08.2020 is: the only convention in common use is yyyy-mm-dd.

> There are no conventions that write a date as mm.dd.yyyy

While slash is the most common, use of hyphens and dots as separators for US-style dates is not at all unheard of in the wild for manually formatted dates. The fact that it doesn't show up in lists of national “preferred formats” and doesn't tend to be commonly implemented as a prebaked format in software doesn't mean it's not a real thing people see and will interpret dates they see in light of.

How is that safe to assume??? You can't assume anything, why not ask the source of the data? The other way is to attempt to confirm which order by looking for first 2 digits > 12, but that info might not be available depending on the data.

Unfortunately, this isn’t true in Canada. MDY is very common, especially in the English parts. See:

https://en.m.wikipedia.org/wiki/Date_format_by_country

MDY separated by dots? The link you gave does not seem to support that.

Separating dates with dots (DD.MM.YYYY) is what’s taught in school in Germany.

So, yeah, there is a convention to write dates exactly that way.

Read the comment again...

It's unambiguous for everybody except Americans with their weird switching.

Does anyone use mm.dd.yyyy?

Germany does. Probably the majority of Europe too

I think you misread: most of mainland Europe including Germany use dd.mm.yyyy or something else that is reasonable sane even if it isn't sortable like yyyy-mm-dd. Or am I wrong on this? Norway at least use mm.dd.yyyy and never mm/dd or mm.dd.yyyy

Afaik Norway also uses the sane format: DD.MM.YYYY

See parent source: https://en.wikipedia.org/wiki/Date_format_by_country

Edit: of course. To late to edit but if you read my post, but that was what I meant.

> The format dd.mm.yyyy using dots is the traditional German date format.

> Since 1996-05-01, the international format yyyy-mm-dd has become the official standard date format

https://en.wikipedia.org/wiki/Date_format_by_country

Schools still teach DD.MM.YYYY. That’s what’s relevant because that’s what people actually widely use.

Shouldn’t Americans be very familiar with the idea that official norms (the metric system) play no role if the people don’t want to use them?

I understand - it seems I was too optimistic to read that the use of yyyy-mm-dd has become "the official standard" in Germany, without considering the popular usage and convention under discussion.

I wish more people complied with ISO 8601.

    https://en.wikipedia.org/wiki/ISO_8601

Even better, wish everyone would standardize on:

* YYYYMMDD for dates

* YYYY-MM for months

* YYYYMMDDTHHMM for time where T is the capital letter T. Two additional digits can be added for seconds and then as many additional digits as needed for precision.

------------------

[Edited for format]

ISO8601

Because it's meant for human consumption. Day and month is usually relevant, while year is less so, so let's put it last.

>2020-08-06 I've just switched to 20200806. Let it be an int and be done with it.

A beautiful property of using ints to represent dates is that you can manipulate them using simple arithmetic. For example, if you want to refer to noon-time on 20200806, you can simply divide the day in two and write it as 10100403. An elegant, DRY solution to a perennial problem.

I don’t get this? What does 10100403 mean?

The poster is gently teasing the idea that integers like 20200806 are a reasonable way to to represent dates. Dividing 20200806 by 2, we get 10100403, representing the half-way point of the day (noon-time). Of course it's nonsense.

I’ve been had

It’s beautiful. Just mod 7 to find the day of the week.

Excellent example. Honestly, I have no idea why the concept hasn't caught on yet.

(I'd love to discuss this further... I'll be back on HN later tonight, sometime around 16834005.)

Human readability sometimes matters.

The integer 20200806 is chosen solely for the purpose of human readability. If you actually wanted to store a date as an integer, you'd use the Julian day.

what human can't parse that? Sure it might take a half a second longer but it's hardly confusing.

For those of us whose professional lives sometimes require staring at directory listings full of filenames like "output-200003021342"... for the love of God, please just put the dashes in.

I have an infinite number of dashes, I'll send you a lifetime supply!

greatideainthesameveinivedecidedtoforgospacesandpunctuationaswellbecauseitsavesspaceaswellaswearandtearonthekeyboard