Yes, it would be nice
if software sorted correctly given DD-MM-YYYY or MM-DD-YYYY. But... it doesn't. Nautilus doesn't, Windows explorer doesn't, ls doesn't. I'd be surprised if any remotely-commonly used file tool did
. (The most likely one would be Finder, but I don't have a Mac to try.)
It's hard enough to convince programmers that "10 - foo" should sort after "2 - foo"
There's a very basic, very important problem there - and that is that there's nothing in the file name or directory structure which explicitly specifies that the "10" in "10 - foo" is a sorting field. It's a mildly irritating problem for those numeric sorting rules - it would be a much larger problem if one attempted to expand the rules to cover date stamps in file names.
Usually that strategy works out alright - you get "Episode_2" before "Episode_10" as you would hope. The problem comes from cases where the file names contain some numeric characters but you actually don't
want the numeric sorting rules triggered. Then, suddenly, the files don't appear where you expect to find them. (I actually did hit a case like this - I think it was in a directory full of files related to Gundam and mecha modeling. I had some photos of model kits, prefixed with their scale, like "1_20_Scopedog.jpeg" and some prefixed with the series they came from, like "0080_zeon.ai" - and some prefixed with other numeric data, like "21C_" as a prefix meaning "21st century"... Numeric sorting rules just make a mess out of that sort of thing, because of all those cases where I have a number at the beginning of the file name, none of them represent the same thing.)
To put it another way - you get the benefit of sorting the way users expect in certain very common cases, but the system produces garbage in cases where a numeric field in the same position may have different meanings. I would argue it's better to choose a simple rule that consistently meets the expectations of users familiar with it, rather than a clever rule that doesn't. Though I think it's also valid to argue that if you become accustomed to the numeric sorting rules, you name your files with this rule in mind to take advantage of it, and avoid those kinds of issues - the user adjusts their behavior to the environment they're used to.
To extend the same rule for dates, the obvious problem is, how can you be sure that a "field" you've picked out of a file name really is a date stamp? It could just be numeric file name characters formatted in such a way that it happens to look like a date. And how do you know which field is the month? You can't rely on the file names matching the machine's locale settings because the file names may have come from another machine (downloaded files of one kind or another). If you don't make it explicit somehow, that that range of characters is a date field (and identify which field is which) you risk sorting things in a way the user doesn't expect, which would in turn make it harder to find the file of interest in a list.
(That's one of the things I really like about Chinese characters - If you see "5月13日" - that's pretty unambiguous... And yet, still very compact.)
The long-term solution, I expect, is to rely more heavily upon metadata other than the file name to obtain sorting fields. We see this happening already - a list of MP3 files in Windows explorer will show ID3 information, and you can sort according to those fields, ignoring the file names entirely... or iPhoto-like collections of photos, in which things are organized by the thumbnail and the age of the file and the tags applied to it, and the user doesn't even care
what the file name is. As people become more accustomed to this style of dealing with files, the practice of relying on "clever" file name sorting will gradually fade into obscurity.