638
ISO 8601 ftw rule (gregtech.eu)
submitted 1 week ago* (last edited 1 week ago) by lena@gregtech.eu to c/196

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

you are viewing a single comment's thread
view the rest of the comments
[-] Umbrias@beehaw.org 1 points 1 week ago

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 week ago* (last edited 1 week ago)

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 week 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 week ago* (last edited 1 week ago)

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 week ago

They chose poor words for this.

[-] Kacarott@aussie.zone 1 points 1 week ago

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 1 week ago

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 1 week ago

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 week 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.

this post was submitted on 26 Jan 2025
638 points (100.0% liked)

196

16867 readers
1743 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