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.
I also do because it is ISO standard. I also do 24 hours for time. I wish scheduling application would do that. I don't know how many times I have scheduled a meeting for 8PM the following day instead of 8AM.
Actually not accurate for "Rest of the World", China uses year month day.
Which is the best date format for sorting stuff alphabetically.
Iso standard time
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.
You're not at all required to specify a time
We are talking about the exakt same thing then. I really like standardized Date formats. They are always pain in programming languages.
That is a timestamp, not a date. 2013-06-13_funnypic.png is better.
Not funnypics but lets say your bills, stuff in your backup:
Gets sorted by name automatically.
I also do because it is ISO standard. I also do 24 hours for time. I wish scheduling application would do that. I don't know how many times I have scheduled a meeting for 8PM the following day instead of 8AM.
@SeaJ I agree on time, 24 hours makes it a lot easier to communicate times with people in other time zones and easier to calculate from GMT.
What china, isn't year-month-day some iso norm?
Yeah, ISO 8601 or better yet: RFC 3339.
(You're actually allowed to read the latter.)
Yeah, just saw that someone mentioned it already.
All of East Asia use the same format.