this post was submitted on 26 Jan 2025
603 points (96.0% liked)

196

16837 readers
1372 users here now

Be sure to follow the rule before you head out.

Rule: You must post before you leave.

^other^ ^rules^

founded 2 years ago
MODERATORS
603
ISO 8601 ftw rule (gregtech.eu)
submitted 3 days ago* (last edited 3 days ago) by lena@gregtech.eu to c/196@lemmy.blahaj.zone
 

!iso8601@lemmy.sdf.org gang, rise up

you are viewing a single comment's thread
view the rest of the comments
[–] Umbrias@beehaw.org 0 points 2 days ago (3 children)

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.

[–] Bo7a@lemmy.ca 2 points 1 day ago* (last edited 1 day ago) (1 children)

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.

[–] Umbrias@beehaw.org 1 points 1 day ago

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.

[–] Bo7a@lemmy.ca 1 points 1 day ago* (last edited 1 day ago) (1 children)

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

5.1. Ordering

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.

[–] Umbrias@beehaw.org 1 points 1 day ago

They chose poor words for this.

[–] Kacarott@aussie.zone 1 points 2 days ago (1 children)

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"

[–] Umbrias@beehaw.org 1 points 2 days ago (1 children)

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.

[–] Kacarott@aussie.zone 1 points 2 days ago (1 children)

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.

[–] Umbrias@beehaw.org 1 points 1 day ago

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.