Clock Change on 25 Oct: Cron Jobs and Shop Timestamps

A classic scheduler compares its fields with the system's current local time. Exactly from this follows the behaviour that the manual page of the cronie line states unusually plainly: non-existent times such as the missing hours during the conversion find no match at all, causing jobs scheduled during those missing times not to be run; times that occur more than once, by contrast, will cause matching jobs to be run twice (crontab(5)). This is not an implementation flaw but the documented consequence of the fact that a local time field is not a unique key during these 60 minutes. A job set to 02:30 local time will be triggered on such a system on 25 October 2026 in hour 2A and again in hour 2B – entirely according to the rules, as far as the scheduler is concerned. It cannot be generalised, though: the cron implementation of the Debian line governs both cases the other way round. When the clock is moved forwards by less than three hours, jobs that would have run in the skipped time are run soon after the change there; when it is moved backwards by less than three hours, jobs that fall into the repeated time are not re-run. Only entries with a fixed time of day are affected, not those with a placeholder in the hour or minute field (cron(8), Debian implementation). Which of the two readings is at work on your own server is answered by its manual page – and that answer decides whether the duplicated, the caught-up or the silent run is the real risk that night.

The second run is rarely harmless. A stock reconciliation that carries deltas forward subtracts the same delta a second time. A dunning run sends the same reminder twice. An invoicing run assigns two number ranges to the same transaction. A payment reconciliation books items twice or fails a uniqueness check and reports an error that nobody can place on Monday. Conversely, the missed run in spring hits hardest those tasks that run only once a day: a nightly backup with a fixed time between 2 and 3 is skipped on a cronie-line scheduler on the March changeover Sunday, and experience shows that the gap is noticed only when somebody attempts a restore. How silent failures of background processes become visible at all is covered in detail by the article on background jobs and cron jobs in a shop; here the separate question of duplicated and skipped runs is at issue. The table below describes a scheduler of the cronie line; on the Debian implementation the duplicated run does not occur and the skipped one is run soon after the change (cron(8), Debian implementation).

The table shows a pattern: what is affected is not the technology but the business logic. Whether a duplicated run causes damage depends on whether the task is repeatable. A cache rebuild tolerates a repetition, a booking does not. The first question before the changeover weekend is therefore not a technical one but a substantive one: which of the tasks running at night change states that cannot be changed twice without consequences? In most shops this list is shorter than it first appears – typically it comes down to a handful of runs around stock, payment and document numbers.

The most widespread misconception is that the database will take care of it. That is half true. For a TIMESTAMP column the rule is: inserted values are converted from the session's time zone to Coordinated Universal Time when stored, and converted back to the session's time zone when retrieved (MariaDB documentation). Internally, therefore, an unambiguous point in time is held. At the same time, however, no time zone identifier is stored with the value (MariaDB documentation). Uniqueness thus depends entirely on the time zone of the writing session – and that can differ between web process, console run and background service without anyone noticing. A DATETIME column, in turn, stores exactly what was written into it, without any reference; within the doubled hour its content is therefore not resolvable.

The changeover is also the reason why a time zone without a date carries no meaning. In another widely used database this is documented explicitly: when a time zone name containing a daylight saving rule is used, specifying the date is required in order to determine whether standard or daylight-savings time applies (PostgreSQL documentation). The standard for date and time on the internet draws the consequence and defines a timestamp as an unambiguous representation of some instant in time (IETF, RFC 3339); numeric offsets there are calculated as local time minus UTC (IETF, RFC 3339), whereas attempts to label local offsets with alphabetic strings have resulted in poor interoperability in the past (IETF, RFC 3339). Translated into practice: store Universal Time or a value with a numeric offset, display local time.

Calling the conversion with a named region instead of a fixed offset presupposes that the database's time zone tables are populated – otherwise the conversion returns no value and the report stays empty without any error being reported. That is one of the typical silent sources of error on this weekend: the query runs through, the output is empty, and the empty output is read as a result. Anyone reviewing data storage regularly anyway will find the matching steps in the article on database maintenance and optimisation.

The rework itself is manageable and fits into a normal maintenance round. It consists of four steps: put schedules on an unambiguous reference, take critical runs out of the window between 1 and 4 local time, secure the repeatability of the remaining runs, and update the rule set of the time zone database. The first step is the most effective. A scheduler that computes in Universal Time knows neither a doubled hour nor a gap, because Universal Time has neither. For a classic scheduler this is done via a time zone declaration in the table itself, for system timers via the calendar field. Whether a time zone declaration in the table is evaluated at all by the cron implementation in use is likewise stated in its manual page; where it is not, it remains an inert variable and the schedule keeps running in local time.

In the calendar expression the time zone is a field of its own: it can be specified as the literal string "UTC", the local timezone, or the timezone in the IANA timezone database format (systemd.time(7)). Without this declaration the system's local time applies – and with it the doubled hour. The second useful switch concerns missed runs: if it is set, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive (systemd.timer(5)). That catches up runs which were missed while the timer was inactive, and for exactly that reason it requires the run to be repeatable – otherwise a missed run is traded for a duplicated one. The switch is no substitute for an unambiguous time specification: it addresses the inactivity of the timer, not the ambiguity of local time. This switch expressly only has an effect on timers configured with a calendar expression (systemd.timer(5)).

The fourth step is readily overlooked. The rules by which a system computes local time come from a continuously maintained database; its current release is 2026c, published on 8 July 2026 (IANA Time Zone Database). That maintenance is not an end in itself: this release alone records Alberta's move to a permanent offset on 18 June 2026 and Morocco's on 20 September 2026 (IANA Time Zone Database). End users typically receive updates to this data through their software and operating system vendors (IANA Time Zone Database) – on a server that means via package management, and thus via the update routine of the maintenance contract. A server whose time zone package has not moved for two years computes with old rules on the changeover days. What role this routine plays in the wider picture is shown by the overview of maintenance services.

The output of zdump is the quickest proof that a system knows the rules: it shows the cut on 25 October 2026 at 01:00 Universal Time and the jump of local time from 02:59:59 to 02:00:00. If that line is missing or names a different date, the rule set is outdated and everything else is moot. The third command answers the second question: which point in time does a calendar expression actually mean? Running it once for the critical schedules shows immediately which runs fall inside the doubled hour. Both checks belong in the same round as scheduling the maintenance window without revenue loss.

On Sunday morning three questions need answering, in this order. First: did every scheduled run execute exactly once? The proof comes from the run record per calendar day, not from the feeling that no alerts arrived – a missed run typically produces no message at all. Second: are there transactions with two bookings, two documents or two messages within the doubled hour? A query over the period from 22:00 Universal Time on the previous day to 02:00 Universal Time, grouped by transaction, is enough for that. Third: do the day's metrics show anomalies that are explained by the extra hour alone? If so, that belongs in a footnote to the report, so that next quarter nobody hunts for a cause that does not exist.

Monday brings the dull but decisive part: whatever stood out that night is written down as a permanent change and not as a note for next time. Schedules still set in local time are converted. Runs that turned out not to be repeatable get a lock per transaction. The next changeover date – the last Sunday in March 2027 – moves into the same calendar as update and certificate deadlines. That is exactly what an SLA maintenance contract is for: it holds such recurring dates so they do not depend on individual memory. A related housekeeping task with the same pattern – recurring, inconspicuous, expensive when it goes wrong – is revoking access during offboarding.