I don't even know why anyone still uses this notation in today's connected world. 2020-08-06 is ideal. Russian standard (06.08.2020) is uglier (digits are not sorted by significance) but still unambiguous. But that slash horror? Why would anyone continue inflicting this on themselves and their peers!?
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:
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.
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.
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.)
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.
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.
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
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.
* 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.
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.
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.
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.
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!
