[HN Gopher] How Debian cron handles DST transitions
___________________________________________________________________
How Debian cron handles DST transitions
Author : zdw
Score : 62 points
Date : 2021-10-27 18:01 UTC (4 hours ago)
(HTM) web link (blog.healthchecks.io)
(TXT) w3m dump (blog.healthchecks.io)
| 0xbadcafebee wrote:
| I hope nobody is depending on cron to be super reliable and
| accurate. If it matters how often a job is run, the job itself
| needs to account for it. Cron is simply not intended to be a
| super robust job scheduler.
| codetrotter wrote:
| The key thing to realize about DST IMO, is the fact that time
| zone is adjusted for it.
|
| So for example I live in Europe/Oslo, which is UTC+02 when DST is
| in effect (CEST). When DST is not in effect, my time zone becomes
| UTC+01 (CET).
|
| And therefore, when we adjust our clocks, time is not really
| moved.
|
| Although it may seem like the time turns back from 3 AM to 2 AM
| on 31 October 2021 in my location, that's only true if you don't
| take the time zone into account.
|
| What actually happens is we go from:
|
| 2021-10-31T02:59:59.999...+0200
|
| to:
|
| 2021-10-31T02:00:00.000...+0100
|
| And we see then that if we convert this time to UTC, we have
| simply a transition from:
|
| 2021-10-31T00:59:59.999...Z
|
| to:
|
| 2021-10-31T01:00:00.000...Z
|
| So actually, nothing bad happened.
|
| The article also says as much, but I wanted to comment on how I
| think about it when I consider DST, because I think it's a pretty
| straight forward way to look at it.
| tshaddox wrote:
| Just to clarify the terminology, since you seem to be referring
| to the widely-used tz database, "time zone" is defined as a
| geographic region where local clocks agree year-round.
| Europe/Oslo is one such time zone in the tz database. Thus your
| time zone does not change when DST begins and ends, only your
| UTC offset.
| codetrotter wrote:
| Yes I may have formulated that part a bit clumsily. What I
| mean to convey is that the time zone changes between CEST and
| CET. And this in turn means different UTC offsets.
|
| The Europe/Oslo identifier from the time zone databases was
| meant for context, but may have made what I tried to say less
| clear, sorry about that.
| birdman3131 wrote:
| (Caveat that this may be US specific.) For the Central time
| zone there are 2 variants. CST and CDT. Most people will
| wrongly use CST to mean both variants but that is incorrect.
| Central Standard Time only applies when daylight savings is
| off and Central Daylight Time only applies when it is on.
|
| The same is true for say PST and PDT.
| tshaddox wrote:
| It's common to casually refer to "CST" and "CDT" as "time
| zones." I was only pointing out that in the specific
| context of the tz database, "time zone" has a specific
| definition that is distinct from individual UTC offsets.
| mdavidn wrote:
| CST and CDT are known as a single time zone,
| America/Chicago, in the tz database. The tz database can
| convert UTC times into local Chicago time. It even
| accommodates historic changes in DST law, like changes to
| the start date in prior years.
| herova wrote:
| DST must die. That's it. It's 21 century already. Why?
| icedchai wrote:
| I'd prefer we stay on daylight time all year around, eliminate
| standard time. (Northeast US here.)
| tzs wrote:
| Because we live on an approximately spherical world whose
| rotation is not tidal locked to the star it orbits, that world
| rotates around an axis that is not perpendicular to its orbital
| plane around said star, we have a biology that uses sunrise to
| synchronize its internal clocks to the planet's rotation, we
| have spread to occupy regions of the world that are not near
| its equator, and we align our timekeeping to midnight or noon.
| dtgriscom wrote:
| A lot of people (myself included) like it. Is that a rational
| reason? No, but it is a portent of how difficult it may be to
| get rid of it.
| function_seven wrote:
| That's a perfectly rational reason! I like it, too.
|
| Yeah, it makes it harder for programmers to accommodate. I'll
| play my violin for them next July when it's nice and bright
| outside at 7:30pm. :)
| tshaddox wrote:
| That might be a valid reason, but it's almost certainly not
| an _explanation_ of why things are the way they are now or
| why they might change in the future. I don 't recall there
| ever being a vote on the subject.
| PetahNZ wrote:
| Because I don't like it getting light at 4am and dark at 5pm.
| flabbergasted wrote:
| As the very last line mentions, "use UTC" and avoid silly DST
| issues like this.
| dbrueck wrote:
| Would that it were so simple! For cronjobs, maybe it often is,
| but DST transitions are a mess to deal with in things like
| calendaring UIs and other places where you have to convert
| point-in-time values to the format consumed by normal people,
| and where your users can have different but legitimate
| expectations about how those transitions should be handled.
|
| At one company I remember helping build a scheduling UI for a
| linear TV broadcast channel, where you plan out the broadcast
| day in 24h blocks. Worked great except twice a year when, due
| to DST, you have either a 23h day or a 25h day, and half a
| dozen ways various customers expected that to be handled. The
| de facto solution was to have happy customers 363 days a year.
| :-/
|
| Hey, but thank goodness for
| https://en.wikipedia.org/wiki/Uniform_Time_Act or it would have
| been even worse!
| midasuni wrote:
| My shop opens when the local clock tower says 9 am
|
| I want a cronjob set up to change the "closed" sigh to say
| "open".
|
| How do I set that with UTC?
| dqv wrote:
| You store the time you want to see on the clock tower and the
| timezone where the clock tower is. Every hour you do the
| following pseudocode: if
| utc_now().to_timzone(my_timezone) >= "9AM": sign
| = "open"
|
| I know you didn't mean this, but it _was_ a problem I thought
| about: How does one make sure the local clock tower actually
| changes in cadence with DST? You can 't, so I guess you could
| use open vz with a camera to have your open sign be based on
| what time is actually seen on the tower.
|
| I know it's just an example, but I say in jest, don't use
| cron jobs to change your closed sign to open! If you can't
| make it to your shop, people will be waiting around all day
| for you to unlock the door. Very unhappy customers.
| blibble wrote:
| some timezones go forwards/back 30 minutes with DST
|
| and historically there have been even weirder cases
| remram wrote:
| This is just duplicating the code already in cron. Of
| course you can make cron simpler by running your script
| every hour, and making the script more complex. You're just
| pushing the complexity to user-authored, non-reviewed, non-
| tested code. What is the advantage?
| dqv wrote:
| The first advantage is that you can dynamically check
| what your actual open hours are rather than having them
| statically configured (e.g. a web service to check for
| holidays). Open hours are never actually static. (Unless
| maybe cron does holidays?)
|
| The second advantage is that you can check in multiple
| timezones especially if the server itself is in DST. Does
| cron itself let you set the timezone for each individual
| check? Or does it only run in one timezone? As far as I
| can tell, it only lets you use one timezone.
| PetahNZ wrote:
| Set the cron job to run every hour in UTC, and your
| application logic checks if its time to open in the
| configured time zone.
| kymaz wrote:
| So the fix to using UTC for computers and crons that only
| care about the local time zone is to reimplement time
| checking?
|
| If youre just gonna run it every hour, you might as well
| while(1){ check time; do stuff; sleep 1 hour;} now there's
| one less dependency?
| rovr138 wrote:
| It depends on that never dying.
| kymaz wrote:
| You also depend on cron never having a bug, and you also
| depend on crons working as intended, unless you also have
| some extra system logging your cron jobs.
| dbaupp wrote:
| Unfortunately there's more ... interesting time zones than
| UTC+/-xx:00, and more interesting transitions than moving
| an hour.
|
| For instance, Nepal uses UTC+05:45, and the time shifted by
| 15 minutes in 1986 (from UTC+05:30):
| https://www.timeanddate.com/time/zone/nepal/kathmandu
|
| That said, I think running every 15 minutes handles all
| currently-observed time zones.
| noja wrote:
| Open your shop at 0900 UTC
| dzdt wrote:
| This is a same problem in financial markets. Things like
| options contracts depend on a value observed say at 10am New
| York time on a particular date a decade in the future. If the
| daylight savings time schedule changes between now and then
| then the UTC time of the expiry of the options contract will
| change. The right reference isnt UTC or EST or EDT but "NY
| local time."
| tshaddox wrote:
| And probably don't schedule anything for the last few seconds
| of a calendar year.
| janiscaune69 wrote:
| End of year is fine, it is around start of day / end of day
| when DST switches that screws up things
| tshaddox wrote:
| I was referring to leap seconds, which are applied at the
| end of the calendar in UTC, and are the only cases where
| UTC is not a continuous and predictable time scale. A
| scheduling system like cron still needs to have some
| mechanism to handle events that are scheduled in UTC,
| because particular UTC seconds can be skipped over. (And
| FYI, this can actually happen in other parts of the
| calendar year, not just the end.)
| mdavidn wrote:
| A leap second would be a change "less than 3 hours," so
| the job should still run according to the cited Debian
| man page.
|
| Google's NTP servers smear leap seconds over an entire
| day, so UTC may appear continuous despite leap seconds.
|
| https://developers.google.com/time/smear
| tshaddox wrote:
| Indeed. I only meant that simply switching to UTC doesn't
| actually reduce the necessity for the complex handling of
| scheduled events this article describes. It would just
| make these cases occur less frequently.
| 0x0 wrote:
| Huh, it's quite surprising to see the concurrent runs at 02:00
| for multiple instances.
|
| I guess this can cause quite a bit of weirdness if you use a spec
| like "5,17,32,47 * * * *" (to avoid the "thundering herd" of
| cronjobs at xx:00) and then getting four concurrent instances
| running at 02:00 in the daylight switchover hour?
| cuu508 wrote:
| The hour specifier in "5,17,32,47 * * * *" is "*", so this
| would count as a wildcard job, and Debian cron would not run it
| at xx:00. But, if the hour specifier started with anything but
| "*", that would be problematic. For example "5,17,32,47 0-23 *
| * *" appears equivalent, but Debian cron _would_ run this one
| four times at xx:00 after a time jump.
|
| Edit: I just ran the second example -
| https://gist.github.com/cuu508/7e42e5eecd42babf43f8d0dd0d987...
| 0x0 wrote:
| Interesting, thanks for running it. And yes I guess I got
| confused with the hour wildcard. So I guess the takeaway is
| to avoid non-wildcarded hours such as 0-23 or 0,1,2,3,4,5,6,7
___________________________________________________________________
(page generated 2021-10-27 23:00 UTC)