Man serveriem ir Rīgas laiks. It kā jau prātīgi būtu to uzstellēt uz UTC, bet nē — man ir vietējais, patriotiski pareizais. Un šodien aizdomājos — a kas notiek ar ieplānotajiem darbiem tad, kad mēs griežam pulksteni?

Kā mēs visi zinām, tanīs liktenīgajās reizēs mums ir jāsagaida pulkstens trīs naktī un jāpagriež visi laikrāži, kuri to nedara paši, uz priekšu vai atpakaļu.

Pirmajā gadījumā, pagriežot laiku pat stundu uz priekšu, vajadzētu izkrist tiem ieplānotajiem darbiem, kuriem bija starp trijiem un četriem? Otrajā gadījumā — vai, pagriežot atpakaļ, darbi, kuri ieplānoti starp diviem un trijiem, izpildās atkārtoti?

Izrādās, ka uz Debian bāzētajām sistēmām ir workarounds. Baigi nepētīju, bet ir aizdomas, ka tas ir visām linux bāzētajām, kuras izmanto oriģinālo vixie-cron (3.0p1). Nav baigi precīzi, bet īsumā — izlaistos darbiņus kaut kad padarīšu, bet notikušos dubultā nelaidīšu. Bet tikai tad, ja laiks nomainās par stundu vai divām.

Special considerations exist when the clock is changed by less than 3 hours, for example at the beginning and end of daylight savings time. If the time has moved forwards, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backwards by less than 3 hours, those jobs that fall into the repeated time will not be re-run.

Only jobs that run at a particular time (not specified as @hourly, nor with '*' in the hour or minute specifier) are affected. Jobs which are specified with wildcards are run based on the new time immediately.

Clock changes of more than 3 hours are considered to be corrections to the clock, and the new time is used immediately.

BSD bāzētajās sistēmas, tai skaitā macOS, cron programmai eksistē speciāls flags -s, ar kuru tā arī darbojas pēc noklusējuma. Tā ietvaros viss, kas darbojas reizi stundā vai biežāk, netiek palaists atkārtoti. Tas, kas darbojas retāk, tiek palaists tad, kad jāpalaiž, neskatoties uz DST.

Enable special handling of situations when the GMT offset of the local timezone changes, such as the switches between the standard time and daylight saving time.

The jobs run during the GMT offset changes time as intuitively expected. If a job falls into a time interval that disappears (for example, during the switch from standard time) to daylight saving time or is duplicated (for example, during the reverse switch), then it is handled in one of two ways:

The first case is for the jobs that run every at hour of a time interval overlapping with the disappearing or duplicated interval. In other words, if the job had run within one hour before the GMT offset change (and cron was not restarted nor the crontab(5) changed after that) or would run after the change at the next hour. They work as always, skip the skipped time or run in the added time as usual.

The second case is for the jobs that run less frequently. They are executed exactly once, they are not skipped nor executed twice (unless cron is restarted or the user's crontab(5) is changed during such a time interval). If an interval disappears due to the GMT offset change, such jobs are executed at the same absolute point of time as they would be in the old time zone. For example, if exactly one hour disappears, this point would be during the next hour at the first minute that is specified for them in crontab(5).

Ja pareizi sapratu, tad oriģinālajā astoņdesmito gadu vixie-cron nekā šāda nebija. Abi risinājumi ir radušies forku rezultātā — gan BSD, gan tas, kas iekš linux.