[petercooper]

I hope we'd all standardize on the opposite: 2017-09-25.. it sorts properly when used in file and document names :-)

[rbanffy]

And all on UTC, please. End this timezone and daylight saving nightmare.

[dkersten]

Yes! If I were dictator of the universe, this would be my first (and possibly only) change.

I'd also like metric time, but abolishing timezones and daylight saving would be more than good enough.

[dingdingdang]

Honestly, the 2017-09-25 format is the only way forward for automatic proper sorting of folder/files..etc.

[tonyedgecombe]

and there is no ambiguity, does 6/7/2017 mean 6th July or 7th June?

[petercooper]

Yeah, I thought about that as I was writing my comment and realized that's why I always write "back to front dates" with dashes instead of slashes. I think it's probably because I always use that format in filenames and slashes feel like a very bad idea there ;-)

[ninjaoxygen]

Yes, it would be so great if there could be a standard for dates formatted this way. It would have to be called something awesome like ISO 8601! ;-)

That is definitely also my preferred format, everything just sorts naturally then. Not so in love with the 2017-09-25T12:00 format as it does not work for filenames on my OS.

[lifthrasiir]

ISO 8601 supports an alternative format without separators, like 20170925T1200.

[linuxlizard]

Obligatory XKCD. https://xkcd.com/1179/

ISO8601 is very nice.

[chuckwnelson]

I love the tongue-in-cheek alt text.

[mrmondo]

Yes that’s a huge problem and I’ve seen a lot of misunderstands from it.

[nsomaru]

I always read that as 6th of the 7th, 2017.

I like American dates for sorting though :)

[oneeyedpigeon]

There definitely still is ambiguity if you're unfamiliar with the format. Show someone "2017-07-06" and they still might be unsure whether that's June or July.

[kbart]

I have never seen YYYY-DD-MM format, on the other hand, both DD/MM/YY and MM/DD/YY are equally common, that's why I always prefer YYYY-MM-DD format as it is the least ambiguous and most useful (sorting files etc., as other comments have mentioned). Feel free to prove me wrong though.

[oneeyedpigeon]

I work with non-techies. Most are totally unfamiliar with YYYY-MM-DD so weren't sure what a date that was ambiguous in that format was. I totally agree that usage of YYYY-DD-MM is rare (in my experience, anyway), but none of these formats fare particularly well when it comes to discoverability.

[robin_reala]

Have you ever been to any of Kazakhstan, Latvia, Nepal or Turkmenistan? https://en.wikipedia.org/wiki/Calendar_date#Gregorian.2C_yea...

[E-M]

I can assure you that Latvia does not use YYYY-DD-MM. Officially Latvia is using ISO 8601. https://en.wikipedia.org/wiki/ISO_8601#Usage

[robin_reala]

I’d update the Wikipedia article but don’t have time to go digging for official sources. Something you (or someone else with domain knowledge) could do?

[kbart]

I've been to Latvia many times in last few years, but haven't noticed YYYY-DD-MM format, maybe it's historical? It looks like DD.MM.YYYY was the most common format there (at least on posters).

[mixmastamyk]

Japan and Denmark use this format.

[mirimir]

If you have enough examples, you can see which field goes over 12. In undocumented datasets, that's the only option.

[majewsky]

That assumes that the dataset is consistent with itself.

[mirimir]

Well, you gotta assume something ;)

And you're right. I've seen some pretty strange stuff.

Sometimes, when forced to use ancient enterprise data systems, desperate staff use abandoned fields for new purposes.

[q-base]

Funny, I never thought about that :) And coming from Denmark I would always have recommended the exact reverse.

[gglitch]

And it can be extended down to arbitrary units.

2017-09-25

2017-09-25-0929

2017-09-25-09290000000000

[maxxxxx]

That would be my dream too :)