1. 17
  1.  

  2. 6

    Interesting read. I still think servers should only ever use UTC as their timezone

    1. 7

      UTC is not monotonically continuously increasing either. Leap seconds can skip your execution moment as well as repeat it.

      1. 4

        Cron generally goes by the minute - so you would need a very large leap second to cause a problem in that case.

        1. 1

          I’m picturing something where the wakeup time is close enough to 1 minute that you could miss a minute. It seems like it will do the right thing if it’s less than a 5 second leap, because they wait up to 65 seconds: https://salsa.debian.org/debian/cron/-/blob/master/debian/patches/features/Better-timeskip-handling.patch#L497

          I think the other time logic would save it in the unprecedented case of 5 leap seconds.

          My point was wrong because I was imagining some sort of sleep that could set you close enough to a minute that even UTC doesn’t help. I didn’t read the code before to see if this happened in the non-patched case. If that were the case, you could possibly want constantly increasing continuous time like GPS time: http://leapsecond.com/java/gpsclock.htm

          1. 1

            I wrote a simple cron and my solution was to wake up in the middle of the minute to give 30 seconds of leeway on either side.

            1. 1

              That’s probably 12 9s of correctness. As backblaze says, there’s more likelihood of an asteroid hitting the earth…

      2. 4

        For sure. But, if a server does use a DST-prone timezone, don’t schedule jobs during the transition.

        PS. My servers are on Hetzner. Hetzner images default to Europe/Berlin, I noticed too late…

      3. 3

        This made me curious to see how systemd timers do it, and they simply don’t

        1. 2

          Does this mean all other UNIX-based OSes (or at least Vixie-cron using distros) don’t do this properly (e.g., running the same job twice when time jumps backwards)? That would be pretty messed up.

          1. 2

            The Debian patch says it’s originally from OpenBSD, so OpenBSD is likely similar. I haven’t experimented with other OSes yet.

            1. 2

              Soo many patches in that repo, and they never went upstream of the whole source became upstream ?!

              1. 1

                the upstream repo looks more nostalgic than really active: https://github.com/vixie/cron

                It looks to me that a community fork to upstream all these things to is better than having all these patches maintained in various distributions.

          2. 2

            The timing on lobste.rs is sometimes irritating. Just yesterday someone opened an issue somewhere else about their system running without a cmos battery, so when they start again their system gets a new time from the internet, and in that second the timer library fires for some hundreds of times.