Daylight Saving Time: The Hour That Comes Twice

What happens in the night of 25 October 2026

The rule sits on two levels. At European level, Directive 2000/84/EC lays down that summer time ends in every member state on the last Sunday in October at 1 a.m. UTC and begins on the last Sunday in March at 1 a.m. UTC (Directive 2000/84/EC). The reference to universal time is the heart of the arrangement: the change happens in every member state at the same instant, only the local time displayed while it happens differs by time zone. Nationally, the German Summer Time Ordinance implements it. It describes the autumn date so that the hour count is set back by one hour from 3 a.m. to 2 a.m., with the hour from 2 a.m. to 3 a.m. appearing twice (Summer Time Ordinance). The two hours even carry official designations: the first is called 2A and is still in summer time, the second is called 2B and is already in standard time (Summer Time Ordinance). In 2026 the last Sunday in October falls on the 25th; the doubled hour begins at 00:00 UTC and ends at 02:00 UTC.

For a system this is a question of uniqueness. A timestamp in universal time denotes an instant; a timestamp in local time denotes a label, and that night the label carries two instants. RFC 9557 puts it this way for conversion in both directions: local times may have zero or multiple possible timestamps because of a nearby daylight saving time change or another change to the UTC offset (RFC 9557). Storing such a value without an offset loses information that cannot be reconstructed later. 02:30 then stops being an instant and becomes a set of two, and neither sorting nor differences nor duration arithmetic get past that to a dependable result.

• 25 October 2026: summer time ends on this day; the directive sets the last Sunday in October at 1 a.m. UTC as the date (Directive 2000/84/EC).
• Two times 2 a.m.: the hour from 2 a.m. to 3 a.m. appears twice; the first carries the official designation 2A, the second 2B (Summer Time Ordinance).
• 169 hours is the length of the week from 19 to 26 October 2026 instead of the usual 168; the week of the spring change accordingly has 167. Both figures follow arithmetically from the doubled and the missing hour and do not appear in the ordinance text.
• 4.6 million responses reached the European Commission in its public consultation on summer time arrangements in the summer of 2018 (European Commission, 2018).
• 84 percent of participants spoke in favour of abolishing the biannual clock change (European Commission, 2018).
• Three releases of the IANA time zone database appeared in 2026 alone: 2026a in March, 2026b in April and 2026c in July (IANA).

For planning purposes what counts is what is in force. The Summer Time Ordinance introduces Central European Summer Time from the year 2002 for an indefinite period (Summer Time Ordinance). Abolition has been under discussion for years: the European Commission ran an online consultation in the summer of 2018, received 4.6 million responses and reported that 84 percent of participants were in favour of ending the biannual change (European Commission, 2018); more than three quarters, 76 percent, rated the change as a negative experience (European Commission, 2018). A proposal then went to Parliament and Council. For day-to-day operations that changes nothing for now. As long as the current arrangement has not been replaced, the change takes place, and systems that do not model it cleanly keep showing up in the same places.

Store UTC, display local time

The rule is old and still holds: instants are stored in universal time and only converted into the viewer's time zone at display time. It sounds banal and in practice rarely fails on intent, but usually on a single column somebody created as local time because it made the display easier. A database column without a time zone stores a label, not an instant. A log format without an offset does the same. It goes unnoticed all year because the mapping between label and instant is unambiguous. In the night of the autumn change it no longer is, and in spring an hour is missing for which no valid label exists at all.

The consequences are unspectacular and therefore hard to find. Two measurements carry the same timestamp yet lie an hour apart. An analysis grouping by timestamp drops two hours into the same bucket and shows twice the number of events for 02:00. A query with a time window returns records twice or not at all, depending on how the bounds are set. A job that stores the last processed timestamp as a marker either reprocesses the second hour or skips it. How long damage of that kind stays unnoticed until somebody deliberately looks is shown for a related case in the article checking character encoding after a migration.

Cron in the doubled hour

Scheduled jobs are the place where the doubled hour becomes visible fastest. The Debian manual page for cron describes the behaviour explicitly: special considerations exist when the clock is changed by less than three hours, as it is at the beginning and end of daylight saving time (Debian, cron(8)). When the clock moves forward, jobs from the skipped time are run shortly after the change. When it moves backward, jobs that fall into the repeated time are not re-run. Only jobs at a specific time are affected; jobs with a wildcard in the hour or minute follow the new time immediately. Clock changes of more than three hours, by contrast, are treated by cron as corrections to the clock and the new time is used immediately (Debian, cron(8)). Other schedulers behave differently, and that is precisely the point: the behaviour is a property of the tool, not a property of time.

• Jobs at 02:30 local time usually run once in autumn and, in spring, run shortly after the change instead of at their intended time.
• Jobs with a wildcard in the hour field follow the new time immediately and therefore run a second time inside the doubled hour.
• Jobs scheduled in universal time are untouched by both; a scheduler planning in UTC knows neither a doubled nor a missing hour.
• Jobs with a lock held through a file or a record run into their own lock in the doubled hour if the key contains local time.

The answer to this is not a calendar entry but a signal. A job that reports in after every run makes the missed run visible without anyone searching through logs on Monday. What that looks like day to day is described in the article heartbeat monitoring for cron jobs; the technical side is at heartbeats. For the night of the change one addition pays off: the expected window gets an extra hour of tolerance for that one night, so the shifted run does not raise a false alert while the missed one still stands out.

A maintenance window that spans the change

A maintenance window is usually agreed in local time, because the people it affects live in local time. It is calculated, however, in real duration. A window from 2 a.m. to 4 a.m. local time lasts three hours in autumn and one in spring. Anyone stating the duration in a contract or an announcement should recalculate on those two days, and anyone hanging alert suppression on it all the more so: suppression that ends an hour early produces alerts in the middle of the work; suppression that ends an hour late hides a real incident. Which mistakes typically occur here is described in the article maintenance windows in monitoring.

The table is not a collection of exceptions to memorise but a single cause in several appearances: local time is a label, universal time is an axis. Everything that calculates in labels loses an hour or invents one on two days a year. In practice that means: windows, deadlines and thresholds are defined as durations and displayed in local time, not the other way round.

What monitoring needs that night

The change is a foreseeable event, and foreseeable events belong in monitoring beforehand rather than in root cause analysis afterwards. Four points typically carry the bulk of the work.

On top of that comes a small organisational detail with a large effect: the time zone of the analysis should be the same as the one the on-call team works in and the one in which clients read their reports. If a report is calculated in universal time and discussed in local time, discussions arise about hours nobody measured. If the time zone is visible in the output, the question is settled in one sentence.

Comparison periods in reports

A weekly report usually compares seven days with the seven days before. In the week of the autumn change that is, arithmetically, 169 hours against 168, in the week of the spring change 167 against 168. The difference is small and still visible as soon as absolute numbers are compared: page views, requests, downtime minutes. For an availability figure it works the other way round, because the denominator changes and the same downtime therefore yields a slightly smaller share. Half a percent of deviation is enough to start a discussion nobody wants to have, while one line in the report footer avoids it.

// Weekly comparison across the autumn change, Europe/Berlin
const start = new Date('2026-10-19T00:00:00+02:00'); // Monday, summer time
const end   = new Date('2026-10-26T00:00:00+01:00'); // Monday, standard time

console.log((end - start) / 3600000); // 169

// Naive arithmetic: seven times twenty-four hours added
const naive = new Date(start.getTime() + 7 * 24 * 3600000);
console.log(naive.toISOString());     // 2026-10-25T22:00:00.000Z

// In local time: 2026-10-25 23:00 CET, one hour short of the end of the week.
// The last measurement of the week drops out of the report.

The snippet shows the mistake in its most common form: seven times twenty-four hours added to an instant yields an endpoint in autumn that lies one hour before the actual end of the week. Anyone forming periods across calendar boundaries therefore calculates with the time zone and not with a fixed distance in milliseconds. That applies to weekly and monthly reports alike, and to every metric that names a preceding period. In reports and on the status page the underlying time zone should therefore appear in the document itself, not only in the setting it was generated from.

A time value without a time zone is not a time value but a guess with four digits.

— XICTRAQ

On call: the shift that is an hour longer

Staffing on-call duty from 10 p.m. to 6 a.m. local time means nine hours in autumn and seven in spring. This is not an academic nicety. The ninth hour falls in the night in which more happens anyway, and in many plans it disappears, because the calendar calculates in local time while compensation hangs on the planned duration. How to build a workable rotation without individual people carrying the load is covered in the article building an on-call rotation.

• Handovers sit at 21:45 or 06:15 local time so that no handover falls inside the doubled hour.
• Escalation deadlines are kept in minutes rather than as a clock time; a deadline of 03:00 local time is ambiguous that night.
• The duty roster states the real duration so that compensation and rest periods match the actual shift.
• The notification carries the instant, the time zone and the offset so the order of two alerts from the same local hour stays readable.

tzdata: the package that ages

The rules themselves do not live in code but in a database. The IANA time zone database holds the history of local time for many regions and is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets and daylight saving rules (IANA). How often that happens is shown by the release list: in 2026 alone three releases of the IANA time zone database appeared, namely 2026a in March, 2026b in April and 2026c in July (IANA). Release 2026c of 8 July 2026 contains, among other things, Morocco's move to a permanent offset of +00 on 20 September 2026 (IANA). A system with an old package gets such changes wrong without producing an error message: it has a rule, it is simply no longer the one in force.

The three calls answer three different questions. The first shows which transition points the system knows for 2026; if there is no transition for 25 October, the package is out of date. The second and the third show the same local time for two instants an hour apart, once with the designation CEST and once with CET. The check takes a minute and makes sense on any system that processes time values, including those that merely pass data on. Interfaces with time values of their own stand out here in particular: a response with local time and no offset is not unambiguous that night, and when an interface is retired the deadline hangs on the same arithmetic, as the article monitoring sunset and deprecation headers shows.

The other direction: the hour that is missing

In spring the case turns around. The Summer Time Ordinance describes the start so that the hour count is moved forward by one hour from 2 a.m. to 3 a.m. (Summer Time Ordinance). The local times between 02:00 and 03:00 do not exist on that day. An application that accepts such a value has three defensible options: reject it, shift it to 03:00, or interpret it as 01:00 universal time. All three are defensible as long as the choice is made deliberately and documented. The fourth case is the expensive one: one library that silently picks one interpretation and a second library in the same system that just as silently picks the other.

For operations the missing hour is the more harmless of the two, because it is loud: a job does not run, an appointment cannot be saved, a conversion throws an exception. The doubled hour is the more expensive one, because it is quiet: everything runs, only the data is wrong. That is why closer scrutiny pays off in autumn. A confirmation flow with a time-limited link illustrates it well: a sixty-minute deadline set at 02:30 local time in the first hour ends at 02:30 local time in the second hour, that is, at the same displayed time one hour later. What else can go wrong along that flow is described in the article monitoring the double opt-in flow.

Checklist for the night

The preparation is an hour of work spread across systems rarely looked after by the same person. Seven points typically cover the bulk of it; they can be worked through in the same order in which the errors would occur.

• Check the time zone of the analysis: in which time zone are reports, charts and exports calculated, and does that time zone appear in the output?
• Review scheduled jobs: which ones run between 01:30 and 03:30 local time, and what happens if one of them is skipped or runs a second time?
• Widen the expectation window: affected heartbeat checks get an extra hour of tolerance for that one night.
• Recalculate maintenance windows: a window in local time has a different real duration that day than planned.
• Check the on-call roster: who has the ninth hour, and does the handover sit outside the doubled hour?
• Update time zone data: check the package version, restart the affected services, verify with one call.
• Fix comparison periods: weekly and monthly reports calculate with calendar boundaries in the time zone rather than with fixed offsets.

After the night: what to look at

On the Monday after the change three looks pay off. First, the list of scheduled runs from that night: if one is missing, the cause is usually the doubled hour rather than the service itself. Second, the event counts per hour: a spike at 02:00 roughly twice as high as the neighbouring hours is not an attack but grouping in local time. Third, the weekly figures: leaving the 169 hours out of account means reporting growth that comes from the change and returns as a decline in spring.

The effort for all of this is small, but it is spread across systems rarely looked after by the same person. That is why it helps to have one place where the time zone is set once and then applies to checks, alerts and reports alike. Anyone who would like to see what that looks like with real measurement series will find an access with sample data under demo; the analysis there states the underlying time zone in every view. That turns the night of 25 October 2026 into what it should be: an hour more sleep for the on-call engineer and one more data point in the analysis.