• @arc@lemm.ee
    link
    fedilink
    2014 days ago

    The sane way of dealing with it is to use UTC everywhere internally and push local time and local formatting up to the user facing bits. And if you move time around as a string (e.g. JSON) then use ISO 8601 since most languages have time / cron APIs that can process it. Often doesn’t happen that way though…

    • @nBodyProblem@lemmy.world
      link
      fedilink
      113 days ago

      The BEST way is to use the number of seconds after the J2000 epoch (The Gregorian date January 1, 2000, at 12:00 Terrestrial Time)

      • @arc@lemm.ee
        link
        fedilink
        112 days ago

        ISO 8601 goes from 1582 (Julian calendar adoption) but can go even further with agreement about intention and goes down beyond the millisecond. Not sure why I want an integer from the year 2000 which only represents seconds.

        • @nBodyProblem@lemmy.world
          link
          fedilink
          111 days ago

          Simplicity and precision.

          Who said it was only measured as an integer? Seconds are a decimal value and many timekeeping applications require higher precision than to the millisecond. Referencing an epoch closer to our current time allows greater precision with a single double-precision floating point number.

          Want to reference something before J2000? Use a negative number.

          It’s independent of earth rotation, so no need to consider leap second updates either unless you are converting to UTC. It’s an absolute measure of time elapsed.