• arc@lemm.ee
    link
    fedilink
    arrow-up
    15
    ·
    edit-2
    7 months ago

    I once developed an electronic program guide for a cable TV company in New Zealand and I’d lose my mind if I had to use timezones. The basic rule of thumb was:

    a) Internally you use UTC religiously. UTC is the same everywhere on Earth, time always goes forward, most languages have classes that represent instants, durations etc. In addition you make damned sure your server time is correct and UTC.

    b) You only deal with timezones when presenting something to a user or taking input from a user

    Prior to that I had worked for a US trading company that set all their servers to EST and was receiving trades through the system which expressed time & date ambiguously. Just had to assume everywhere that EST was the default but it was just dumb programming and I bet to this day every piece of code they develop has time bugs.

    • letsgo@lemm.ee
      link
      fedilink
      arrow-up
      7
      arrow-down
      2
      ·
      7 months ago

      Standardising on EST is fine; it’s just UTC plus a constant. If they flipped between EST and EDT, now that’d be insane.

      • arc@lemm.ee
        link
        fedilink
        arrow-up
        6
        ·
        7 months ago

        Yes as long as the rules are known, but it’s really just better to do things sanely and leave no margin of doubt.

        • loutr@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          Yep, case in point flipping between EST and EDT may be “insane” but that’s the default for systemd-timesyncd. So now you have to be 100% certain that it’s disabled on your servers, and on the remote hosts interacting with them.

      • BeardedGingerWonder@feddit.uk
        link
        fedilink
        English
        arrow-up
        3
        ·
        7 months ago

        Best I’ve seen is a process scheduled on UK local time (including hour changes) running on a server that maintains Eastern local (including hour changes) but the process logs in EST ( and does not move with the hour)

    • uis@lemm.ee
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      7 months ago

      time always goes forward

      It not always goes and not always forward. I think you need metric time(TAI) instread.

      • arc@lemm.ee
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        7 months ago

        UTC always goes forward regardless of the timezone and local time. That is why you should use it. To take my EPG situation above, I stored program start / end times in UTC so they would render properly even if DST kicked in or not during the middle of the program.

        • uis@lemm.ee
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          7 months ago

          Ok, this is more unix time quirk that can’t handle 24:00:00 and skipping 23:59:59.

          UTC always goes forward regardless of the timezone and local time

          But not unix time.

          I stored program start / end times in UTC

          If your program finishes in less than one seond it might report negative time.

          • arc@lemm.ee
            link
            fedilink
            arrow-up
            4
            ·
            7 months ago

            I didn’t say Unix time, I said UTC. And no it won’t report negative time, not unless somehow the system clock was modified while it was running…

            • uis@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              7 months ago

              not unless somehow the system clock was modified while it was running…

              Which is how most systems handle leap seconds.

              • arc@lemm.ee
                link
                fedilink
                arrow-up
                1
                arrow-down
                1
                ·
                edit-2
                7 months ago

                Leap seconds still make time go forwards, not backwards. NTP clients would also resolve small time discrepancies while still advancing forwards prior to the next time sync.

                • uis@lemm.ee
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  7 months ago

                  Leap seconds can make time go both ways, but adding them makes time stop/go back because 24:00:00 cannot be represented as 1/86400 part of day N instead of day N+1 on major OSes. And they were only added so far.

                  • arc@lemm.ee
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    edit-2
                    7 months ago

                    It doesn’t work like that. UTC goes forward always. Leap seconds are scheduled and known in advance. NTP time services will just smear time advancement a little to account for an additional second. Time never has to go backwards. This is how Google does it.