That’s also great, but unhandy for manual use. Imaging a folder full of files like:
2004-06-14T23:34:30+02:00_funnypic.png
04-06-13_funnypic.png is much better in that regard, but obviously is not that precise.
If you don’t butcher it like you did, ISO8601 caters for any amount of precision you need.
For the vast, vast majority of my usage 2023-07-23 is sufficient. If you need a time as well just append the time and the nice thing is it’ll still keep things in order (I’ve not found myself needing to use the timezone notation as well since I don’t usually share dates cross-border). For work I use the week notation a lot 2023-W30-4.
04-06-13 is not helpful because now I don’t know if you’re European and mean 4th of June 2013, or if you’re american and mean 6th of April 2013, or if you’re some weirdo who means 13th of June 2004.
These are the iso standard timestamps I regularly use in code, which are precise but unhandy. There is no butchering, it’s just one of the full standards.
As I said above it’s highly unhandy to use the full string. The shortened two digits version is fully sufficient when operating in a controlled environment, because you know what each pair represents. As soon as you go into the great unknown, you can’t say for sure what format is used anyway.
What we can definitely agree on, is that a standard process would help a lot, whichever it is. Preferably one that works well with alphabetically sorting.
