• Umbrias@beehaw.org
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    3 days 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
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      2 days 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
        link
        fedilink
        arrow-up
        1
        ·
        2 days 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
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      2 days 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.

    • Kacarott@aussie.zone
      link
      fedilink
      arrow-up
      1
      ·
      3 days 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
        link
        fedilink
        arrow-up
        1
        ·
        2 days 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
          link
          fedilink
          arrow-up
          1
          ·
          2 days 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
            link
            fedilink
            arrow-up
            1
            ·
            2 days 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.