5 ms·
How Debian cron handles DST transitions
- flabbergasted 5y agoAs the very last line mentions, "use UTC" and avoid silly DST issues like this.
- tshaddox 5y agoAnd probably don't schedule anything for the last few seconds of a calendar year.
- janiscaune69 5y agoEnd of year is fine, it is around start of day / end of day when DST switches that screws up things
- tshaddox 5y agoI 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 5y agoA 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 https://developers.google.com/time/smear
- tshaddox 5y agoIndeed. 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.
- midasuni 5y agoMy 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?
- noja 5y agoOpen your shop at 0900 UTC
- PetahNZ 5y agoSet 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 5y agoSo 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?
- dbaupp 5y agoUnfortunately 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 https://www.timeanddate.com/time/zone/nepal/kathmandu That said, I think running every 15 minutes handles all currently-observed time zones.
- dbrueck 5y agoWould 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 https://en.wikipedia.org/wiki/Uniform_Time_Act or it would have been even worse!
- mason55 5y agoA better answer is to use time+locale for things that are supposed to happen in the future and UTC for things that happened in the past. The reason is that things that happened in the past will have a specific moment on the arrow of time at which they happened, and UTC is as good as anything else for putting a consistent label on the arrow of time. But, for things that are going to happen in the future, you have no way of knowing if two "time labels" that right now point to the same moment on the arrow of time might have some change that causes them to point to different moments. In this case UTC removes the ambiguity about the timezone that the time is in, but it adds ambiguity about which moment in time you're really talking about. Let's say you want to schedule something for 9pm local time (UTC-3). So you schedule it for midnight UTC. Then your timezone shifts to UTC-2 and your appointment moves to 10pm. That's likely not at all what you intended. It's also why you need to pick a "master" timezone when you're sending invites to multiple timezones and let the rest of the times be derived from the "single source of truth" time.
- stefan_ 5y agoThis heuristic obviously doesn't work. I build a factory in a strategy game. It is going to take 10h. The timezone shifts; should it take longer, shorter, the same? Obviously the same. You still need to use your brain and careful UI design. Things that a user scheduled to happen at a specific local time need to store the relevant timezone, implicitly or explicitly.
- codetrotter 5y agoThe 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 5y agoJust 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 5y agoYes 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 5y ago(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.
- 0x0 5y agoHuh, 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 5y agoThe 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/7e42e5eecd42babf43f8d0dd0d9873a5 https://gist.github.com/cuu508/7e42e5eecd42babf43f8d0dd0d987...
- 0x0 5y agoInteresting, 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
- herova 5y agoDST must die. That's it. It's 21 century already. Why?
- jrmg 5y agoBecause I enjoy having light in my morning in Winter, but allowing the extra hours of daylight to accumulate in the evening in summer. The slight disconcertingness of the hour changes is worth it.
- dtgriscom 5y agoA 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 5y agoThat'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 5y agoThat 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.
- necubi 5y agoCalifornia voted in 2018 to abolish DST (https://en.wikipedia.org/wiki/2018_California_Proposition_7 https://en.wikipedia.org/wiki/2018_California_Proposition_7) — and it won 60%/40% (technically to allow the legislature to do it).
- tshaddox 5y agoAn important technicality, since it's now 2021 and we are still observing DST.
- 0xbadcafebee 5y agoI 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.
- runpkins 5y agoThe manual page is wrong. The UNIX clock is UTC, so DST transitions aren't a clock change, they're a local time discontinuity. I'm pretty sure the article is wrong, too, because it implies that a DST transition won't cause cron jobs to be skipped or run twice. But it looks like the logic in Better-timeskip-handling.patch doesn't account for the possibility that the computer might be rebooted near a DST transition. Reboot immediately after the time falls back and it'll happily run the cron job a second time. The right way to handle this would have been to internally convert the crontab entries to UTC before scheduling them. It's surprising that OpenBSD (the origin of this patch) blundered this - usually they get the details right.
- xyzzyz 5y agoIn what sense Unix clock is UTC? Unix clock is to a first approximation defined as number of second that have passed since a particular fixed point in time. As such, timezone considerations are pretty much immaterial to what Unix clock is. This definition of Unix clock is only mostly correct, due to its treatment of leap seconds, but the way they are treated in Unix clock is not like how they are treated in UTC anyway (some Unix seconds last 2 SI seconds), so in this sense, Unix clock is not UTC either.
- deleted 5y ago[deleted]