CyberNative

Sunday 1 November 2026 · Los Angeles time

01:00 came twice.

After 01:59:59 daylight time, clocks went back to 01:00 standard time, and the same hour ran a second time. We reproduced four programs that went wrong in the second pass: two went silent, one had its daily report due again, one set the server clock back an hour.

  • systemd timer, every 20 min
  • hermes-agent cron, every 5 min
  • 1Panel time sync, 01:30
  • OpenCVE daily report, 01:00
  • Due but silent
  • Ran or due again
Los Angeles, 1 November 2026: the hour from 01:00 to 01:59 drawn as two turns of one clock. Inner turn: the first 01:00 to 01:59, daylight time, 08:00 to 09:00 UTC. Outer turn: the second 01:00 to 01:59, standard time, 09:00 to 10:00 UTC. In the first turn every job runs. In the second, the systemd timer and the hermes-agent cron job are silent, the OpenCVE 01:00 report is due again, and the 1Panel time sync runs again and sets the server clock back one hour. The same facts are listed as text below the figure. 01:00 PDT 08:00 UTC 01:00 PST 09:00 UTC 02:00 PST 10:00 UTC 01:30: clock set back 1 h 01:00 twice
Inner turn: the first 01:00–01:59 (08:00–09:00 UTC). Outer turn: the second (09:00–10:00 UTC). New York’s second 01:00 came three hours earlier, at 06:00 UTC.

Same minute on the clock, different result

Each bar is one pass through 01:00–01:59, the first above the second, so the same minute lines up. Hollow rings were due and did not run.

systemd timer every 20 minutes

OnCalendar=*-*-* *:05,25,45:00

First 01:00
Ran at 01:05, 01:25 and 01:45.
Second 01:00
Silent. Next run at 02:05.

On our own server (systemd 259.9, Los Angeles time) the timer went 80 real minutes between runs on a 20-minute schedule. Timers written with hourly, minutely or a step such as *:0/20 lose the second pass the same way; a fixed time like 01:30 runs once, which is right.

What helps Add UTC to the end of the line: OnCalendar=*-*-* *:05,25,45:00 UTC. Only for repeating times: on a fixed time, UTC moves the hour (01:30 UTC is 17:30 the evening before in Los Angeles). Checked with systemd-analyze calendar, not on a live unit.

Upstream issue open since 2018 (systemd#8647). Tested on 259.9 only. Seen in our server journal; reproduced with systemd-analyze.

hermes-agent cron every 5 minutes

*/5 * * * *

First 01:00
12 runs, 01:00 to 01:55.
Second 01:00
Silent. Next run at 02:00.

A reporter's live gateway ran a */5 job at 08:55 UTC and then 10:00 UTC. We reproduced it with croniter 6.2.4: 12 runs in the two real hours where 24 were due, a 65-minute gap. */15, */20 and hourly jobs lose the second pass too.

What helps Use an interval schedule such as every 30m instead of a cron line: intervals count real time and were not affected.

Issue #147553 open, no fix. Latest release v0.22.5. Reproduced on a copy of the scheduling function, not the full program.

1Panel time sync at 01:30

30 1 * * *

First 01:00
Synced the clock at 01:30.
Second 01:00
Ran again at 01:30 and set the server clock back one hour.

The sync writes the time without its UTC offset (2026-11-01 01:30:00). In the second pass, date -s reads that as daylight time, so the clock jumped from about 09:30 UTC back to 08:30 UTC. The reporter's server logged “System clock wrong by 3600.048672 seconds”.

What helps Don't run the built-in sync between 01:00 and 02:00 on the night clocks go back, or set the time with date -u -s @<epoch>.

Issue #14265 open. v2.4.2, the latest release, has the same code. Cause reproduced with GNU date 9.7; we did not move a real clock. The jump is from the reporter's logs.

OpenCVE daily report at 01:00

daily, 01:00 local

First 01:00
Due at 01:00.
Second 01:00
Due again at 01:00.

Each hour the scheduler asks whether the local time is 01:00. On this night it is, twice, so a daily report at 01:00 was due twice in New York, Chicago, Denver and Los Angeles. Schedules at 02:00 and 09:00 were due once.

What helps Fix proposed in pull request #803; it gave one due time in every case we ran.

Issue #801 and pull request #803 open, not reviewed. Latest release v3.1.0. Reproduced the due-time query on PostgreSQL 17.11, not a full Airflow run.

Where the hour should not have repeated

Cuba and western Canada did not turn their clocks back this year. Software with old time-zone data turned them back anyway, and it still shows the time an hour behind.

PlaceOld data turned clocks back (local)UTCWhy it is wrong
Havana01:00 back to 00:0005:00Cuba kept daylight time. Old data turned clocks back anyway, and they stay an hour behind until 14 March 2027. Guide
Winnipeg02:00 back to 01:0007:00Manitoba stopped changing clocks. Guide
Edmonton, Calgary, Inuvik02:00 back to 01:0008:00Alberta and the Northwest Territories stopped changing clocks. Guide
Vancouver02:00 back to 01:0009:00British Columbia stopped changing clocks; data older than April's 2026b is wrong. Guide

Still wrong after updating, in our 27 October tests: Java 8 and 11 (Temurin), PHP 8.2 and 8.3, Go in scratch images, Kubernetes CronJobs with timeZone. Grafana 13.3.0 carries its own time-zone table, and it shows all four places an hour behind; the open fix covers Vancouver only.

How we know

Each program was run in a contained test on 1 November 2026 against the version named, or seen on our own server. We did not change a real clock. A report we could not reproduce is left off this page. Upstream status read at 16:42 UTC on 1 November.

Before the night we published a check for five other schedulers: will your scheduled job run twice, loop or skip.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. If something on this page is wrong or has changed, email hello@cybernative.ai.