I like my dates sorted by how likely it is that I need that information.
Most things I refer to by date happen in the current year and the current month. So using day first means in many cases I can stop right there.
If something’s not happening this month, then it’s likely to happen in the current year, thus month next. And only if that fails I need to put a year.
Following the same logic, you get the opposite for time:
Most things referred to by time happen sometime today but likely not within the same hour (otherwise I’d rather say “In 10 minutes”). And often the hour is precise enough and I don’t need minutes. So hour first.
If hours are not exact enough, minutes likely are, so minutes next. And only when that is not precise enough will I mention seconds or milliseconds.
This gives me a format of dd.mm.yyyy and hh:mm:ss.msms
It doesn’t have to be superior in every case to fit some use cases better. They probably won’t ever need to work with hundreds of thousands of date stamps, so why should they select a date system based on that?
I literally never do that. I don’t even know what type of file a person would save under just a date- screen grabs from security footage maybe? I use names, because I can already sort by the creation date and I won’t know what each file is without a name.
Again, each person uses dates differently and it would be silly for me to prefer that one because it might be better when doing something I’ve never done.
I often like to differentiate between edit date and creation date. Also depending on a file is transferred the date might be reset to the current date.
I like my dates sorted by how likely it is that I need that information.
Most things I refer to by date happen in the current year and the current month. So using day first means in many cases I can stop right there.
If something’s not happening this month, then it’s likely to happen in the current year, thus month next. And only if that fails I need to put a year.
Following the same logic, you get the opposite for time:
Most things referred to by time happen sometime today but likely not within the same hour (otherwise I’d rather say “In 10 minutes”). And often the hour is precise enough and I don’t need minutes. So hour first.
If hours are not exact enough, minutes likely are, so minutes next. And only when that is not precise enough will I mention seconds or milliseconds.
This gives me a format of
dd.mm.yyyyandhh:mm:ss.msmsMany people have jobs that entail (essentially) fixing others’ mistakes. One doesn’t discard history at the start of each year.
Some people are just too enamoured by the yyyy mm dd format they just cannot see the pros of the dd mm yyyy system
Because it’s not actually superior. You just haven’t dealt with hundreds of thousands (millions, billions) of timestamps in one table, for example
It doesn’t have to be superior in every case to fit some use cases better. They probably won’t ever need to work with hundreds of thousands of date stamps, so why should they select a date system based on that?
I would argue that it is superior once you have prefixed three files from two months with a date.
I literally never do that. I don’t even know what type of file a person would save under just a date- screen grabs from security footage maybe? I use names, because I can already sort by the creation date and I won’t know what each file is without a name.
Again, each person uses dates differently and it would be silly for me to prefer that one because it might be better when doing something I’ve never done.
I often like to differentiate between edit date and creation date. Also depending on a file is transferred the date might be reset to the current date.
Oh yes because I look at millions of timestanps on a daily basis?
I never said the system you use is not better for certain use cases.
I just said that you are too into it to realise the dd mm system just works better for everyday life and common people.
If it’s for the front-end, you can represent it however you want. But yyyymmdd is the way to store it.