You are looking not for precision but for largest to smallest, descending order. this is distinct from precision, a measure of how finely measured something is. 2025.07397 is actually more precise than 2025/01/27, but is measured by the largest increment.
And to address the argument on precision versus descending. I disagree. An instrument counting seconds is more precise than a machine counting minutes, hours, days, weeks, months etc… And that holds true through the chain. The precision is in the unit.
the unit is just a report of orientation, not magnitude. if you have a digital counter you are limited by the precision of the digital counter, not the units chosen. an analog measurement however is limited instead by other uncertanties. precision has, genuinely, no direct relationship to units. precision is a statistical concept, not a dimensional one.
If date and time components are ordered from least precise to most
precise, then a useful property is achieved. Assuming that the time
zones of the dates and times are the same (e.g., all in UTC),
expressed using the same string (e.g., all “Z” or all “+00:00”), and
all times have the same number of fractional second digits, then the
date and time strings may be sorted as strings (e.g., using the
strcmp() function in C) and a time-ordered sequence will result.
largest to smallest is correct. 1 mile is larger than 20 meters. if i had specified numerical value or somesuch, maybe you’d be correct. though significance works as well.
Largest to smallest is at best ambiguous. It can refer to the size of the number itself, or the size of the unit.
There is a reason this exact concept in maths/computer science is known as the “significance” of the digit. Eg. The “least significant bit” in binary is the last one.
significance refers to a measurement certainty about a number itself, especially its precision! and is unrelated to the magnitude/scale. the number and dimension “2.5634 mm” has more significant digits than the number “5,000 mm”, though the most significant digit is 2 and 5 respectively, and least significant 4 and 5 respectively. this is true if i rewrite it as 0.0025634 m and 5 m. it does work for doing what you say in this case because a date is equivalent to a single number, but is not correct in other situations. that’s why i said it does work here.
largest to smallest increment is completely adequate, and describes the actual goal here well. most things are ambiguous if you try hard enough.
Sorting with either the month or the day ahead of the year results in more immediately relevant identifiable information being displayed first. The year doesn’t change very often, so it’s not something you necessarily need to scan past for every entry. The hour changes so frequently as to be irrelevant in many cases. Both the month and the day represent a more useful range of time that you might want to see immediately.
Personally, I find the month first to be more practical because it tells you how relatively recent something is on a scale that actually lasts a while. Going day first means if you’ve got files sorted this way you’re going to have days of the month listed more prominently than months themselves, so the first of January through the first of December will all be closer together then the first and second of January in your list. Impractical.
Year first makes sense if you’re keeping a list around for multiple years, but the application there is less useful in the short term. It’s probably simpler to just have individual folders for years and then also tack it on after days to make sure it’s not missing.
Also, like, this format is how physical calendars work assuming you don’t have a whole stack of them sitting in front of you.
You misunderstand my comment.
I’m saying the digits in a date should be printed in an order dictated by which units give the most precision.
A year is the least precise, a month is the next least, followed by day, hour, minute, second, millisecond.
You are looking not for precision but for largest to smallest, descending order. this is distinct from precision, a measure of how finely measured something is. 2025.07397 is actually more precise than 2025/01/27, but is measured by the largest increment.
And to address the argument on precision versus descending. I disagree. An instrument counting seconds is more precise than a machine counting minutes, hours, days, weeks, months etc… And that holds true through the chain. The precision is in the unit.
the unit is just a report of orientation, not magnitude. if you have a digital counter you are limited by the precision of the digital counter, not the units chosen. an analog measurement however is limited instead by other uncertanties. precision has, genuinely, no direct relationship to units. precision is a statistical concept, not a dimensional one.
We can debate this all day. And I can’t honestly say that I would take either side in a purely semantics argument.
But the wording comes directly from RFC3339 which is, to me, the definitive source for useful date representation.
https://www.ietf.org/rfc/rfc3339.txt
They chose poor words for this.
Largest to smallest is also wrong. In 2025/01/28, the 28 is larger than the 01.
It should be “most significant” to “least significant”
largest to smallest is correct. 1 mile is larger than 20 meters. if i had specified numerical value or somesuch, maybe you’d be correct. though significance works as well.
Largest to smallest is at best ambiguous. It can refer to the size of the number itself, or the size of the unit.
There is a reason this exact concept in maths/computer science is known as the “significance” of the digit. Eg. The “least significant bit” in binary is the last one.
significance refers to a measurement certainty about a number itself, especially its precision! and is unrelated to the magnitude/scale. the number and dimension “2.5634 mm” has more significant digits than the number “5,000 mm”, though the most significant digit is 2 and 5 respectively, and least significant 4 and 5 respectively. this is true if i rewrite it as 0.0025634 m and 5 m. it does work for doing what you say in this case because a date is equivalent to a single number, but is not correct in other situations. that’s why i said it does work here.
largest to smallest increment is completely adequate, and describes the actual goal here well. most things are ambiguous if you try hard enough.
Sorting with either the month or the day ahead of the year results in more immediately relevant identifiable information being displayed first. The year doesn’t change very often, so it’s not something you necessarily need to scan past for every entry. The hour changes so frequently as to be irrelevant in many cases. Both the month and the day represent a more useful range of time that you might want to see immediately.
Personally, I find the month first to be more practical because it tells you how relatively recent something is on a scale that actually lasts a while. Going day first means if you’ve got files sorted this way you’re going to have days of the month listed more prominently than months themselves, so the first of January through the first of December will all be closer together then the first and second of January in your list. Impractical.
Year first makes sense if you’re keeping a list around for multiple years, but the application there is less useful in the short term. It’s probably simpler to just have individual folders for years and then also tack it on after days to make sure it’s not missing.
Also, like, this format is how physical calendars work assuming you don’t have a whole stack of them sitting in front of you.
By keeping years in different folders you are just implicitly creating the ISO format: eg.
2025/"04/28.xls"Well, not really. Sort of.
2025/“04-28-2025.xls”
You still want the year in the title format so you have it if it ends up on its own somewhere.