At 1:59:59 a.m. on Sunday, November 1, 2026, clocks in New York will not tick over to 2:00. They will jump back to 1:00:00 a.m., and the next 60 minutes will replay. Every time from 1:00 to 1:59 happens twice that night, once on Eastern Daylight Time and once on Eastern Standard Time. Europe goes through the same thing a week earlier, on October 25, 2026, but in a different local hour.
For most people the repeat means an extra hour of sleep. For anyone whose work depends on timestamps, such as payroll, hospitals, power grids, schedulers or databases, it means a stretch of time in which “1:30 a.m.” does not identify a single moment.
What happens on the clock, second by second
In the United States, federal law sets the end of daylight saving time at 2:00 a.m. local time on the first Sunday of November, a schedule in place since 2007 under the Energy Policy Act of 2005. At that moment, local time goes back one hour. In the Eastern zone, the sequence looks like this:
- 1:59:59 a.m. EDT (UTC−4), which is 05:59:59 UTC
- 1:00:00 a.m. EST (UTC−5), which is 06:00:00 UTC
Nothing happens to physical time. UTC keeps counting forward without a pause, and Unix time, which counts seconds since 1970 in UTC, doesn’t notice the change at all. Only the local label resets. The result is a 25-hour calendar day: November 1, 2026 runs from midnight EDT to midnight EST, and 25 hours pass in between.
The change doesn’t happen everywhere at once. Each US time zone falls back at 2:00 a.m. its own local time, so the switch sweeps west across the country at hourly intervals: 06:00 UTC in the Eastern zone, 07:00 UTC in the Central, 08:00 UTC in the Mountain, 09:00 UTC in the Pacific and 10:00 UTC across most of Alaska, with the western Aleutian Islands following at 11:00 UTC. Most of Arizona and all of Hawaii don’t observe daylight saving time and never repeat an hour.
Which hour repeats depends on where you are
Europe uses the opposite design. EU Directive 2000/84/EC ends summer time at 1:00 a.m. UTC on the last Sunday of October in every member state at the same instant. Because each country sits at a different offset from UTC, that single moment carries a different local label in each zone, and so does the repeated hour.
| Region (2026 date) | Clocks go back | Local hour that repeats | First pass (UTC) | Second pass (UTC) |
|---|---|---|---|---|
| US Eastern (Nov 1) | 2:00 EDT to 1:00 EST | 1:00 to 1:59 | 05:00 to 05:59 | 06:00 to 06:59 |
| US Central (Nov 1) | 2:00 CDT to 1:00 CST | 1:00 to 1:59 | 06:00 to 06:59 | 07:00 to 07:59 |
| US Pacific (Nov 1) | 2:00 PDT to 1:00 PST | 1:00 to 1:59 | 08:00 to 08:59 | 09:00 to 09:59 |
| UK, Ireland, Portugal (Oct 25) | 02:00 to 01:00 | 01:00 to 01:59 | 00:00 to 00:59 | 01:00 to 01:59 |
| Central European Time: Germany, France, Spain, Italy (Oct 25) | 03:00 CEST to 02:00 CET | 02:00 to 02:59 | 00:00 to 00:59 | 01:00 to 01:59 |
| Eastern European Time: Finland, Greece, Romania (Oct 25) | 04:00 EEST to 03:00 EET | 03:00 to 03:59 | 00:00 to 00:59 | 01:00 to 01:59 |
In Europe, the repeated hour is the same two hours of UTC everywhere, with a different local label in each zone. In the United States, it is the same local label, 1:00 to 1:59 a.m., replayed at a different UTC moment in each zone. worldtimedata
That difference matters for anyone reading about the “2 a.m. change” in Europe. It is true for Berlin and Paris, where 02:00 to 02:59 repeats, but in London and Dublin the repeated hour is 01:00 to 01:59, and in Helsinki and Athens it is 03:00 to 03:59. And because Europe changes on the last Sunday of October and the US on the first Sunday of November, which are always consecutive Sundays, the two sides are out of step for exactly one week each autumn. In 2026, from October 25 to November 1, New York is four hours behind London instead of the usual five.
How to tell the two 1:30s apart
A local time on its own is ambiguous during the repeated hour. Adding the UTC offset fixes it. In ISO 8601 notation, the first and second 1:30 a.m. in New York on November 1, 2026 are:
- 2026-11-01T01:30-04:00 (EDT, first pass), which is 05:30 UTC, Unix time 1793511000
- 2026-11-01T01:30-05:00 (EST, second pass), which is 06:30 UTC, Unix time 1793514600
The two Unix timestamps differ by exactly 3,600 seconds, which makes the point: they are two distinct moments an hour apart that happen to share a wall-clock reading. The zone abbreviation does the same job in plain language, which is why the difference between EST and EDT is not pedantry on this one night. Aviation, the military and many logging systems avoid the problem entirely by recording everything in UTC, the convention behind Zulu time.
Where the repeated hour causes real problems
Night shifts and time sheets
A worker on a 10 p.m. to 6 a.m. shift that crosses the fall-back night is on the job for nine real hours, not eight. Under the Fair Labor Standards Act, nonexempt employees must be paid for hours actually worked, so that extra hour counts, and it can push a worker into overtime. The same applies to hospital staff on 12-hour night shifts, who work 13. Timekeeping systems that store only local time can get this wrong in two ways. They can compute an 8-hour shift from the wall-clock start and end. Or, if someone clocks in at 1:45 a.m. on the first pass and out at 1:10 a.m. on the second, 25 real minutes later, a naive subtraction produces minus 35 minutes.
Hourly reports and power markets
Any report organized by hour of the day has to show 25 rows on the fall-back date, and any “daily” total covers about 4.2% more time than usual (25 hours instead of 24). Electricity markets, which settle by the hour, handle this with explicit labels. The Texas grid operator ERCOT labels the repeated hour 0200* on its long day, listing 0100, 0200, 0200* and 0300. PJM, the grid operator for much of the eastern US, labels the second hour ending 02 as “HE 02*” in its reports, and some of its downloadable files carry a 25th hour column every day of the year, filled with zeros except on the fall-back date. In both systems, “hour ending 2” is the interval from 1:00 to 2:00 a.m., which is exactly the hour that repeats.
Scheduled jobs
The classic Unix scheduler, cron, has explicit rules for this night. According to the Debian and Ubuntu manual pages for Vixie cron, when the clock moves backward by less than three hours, jobs set for a specific time inside the repeated hour are not run a second time. But jobs defined with wildcards in the hour or minute field, such as a task that runs every 15 minutes, follow the new time immediately and run in both passes. A backup scheduled for 1:30 a.m. runs once, on the first pass; a job scheduled for every 15 minutes runs eight times between the first 1:00 and 2:00 instead of four. Other schedulers handle the transition in their own ways, which is why a common practice is to keep critical jobs out of the 1:00 to 3:00 a.m. window, or to run servers on UTC.
Software that has to choose one
Programming libraries need a rule for converting an ambiguous local time into a single moment, and they document it explicitly. Python added a fold attribute to its datetime objects in version 3.6 (PEP 495): fold=0 means the first occurrence of a repeated time, fold=1 the second. Java’s ZonedDateTime defaults to the earlier offset when a local time falls in an overlap. JavaScript’s newer Temporal API takes a disambiguation option with the values “earlier”, “later”, “compatible” and “reject”, so the developer states the choice rather than inheriting it. All of these rely on the tz database, which is why software should store an IANA time zone name like America/New_York instead of a fixed offset: only the named zone knows when the offset changes.
Birth certificates
The repeated hour occasionally makes the paperwork contradict the order of events. On November 6, 2016, at Cape Cod Hospital in Massachusetts, Samuel Peterson was born at 1:39 a.m. EDT. His twin brother Ronan arrived 31 minutes later, by which time clocks had fallen back, so his recorded time of birth was 1:10 a.m. EST. On paper, the second-born twin is 29 minutes older. A maternity nurse with more than 40 years on the job said it was the first time she had seen it happen.
Trains running on schedule
Transport timetables published in local time face the same problem from the other direction. An overnight train that is on schedule when clocks fall back suddenly finds itself an hour early by the new clock. Amtrak’s long-standing practice, widely described by rail staff and passengers, is for such trains to hold for an hour, usually at a station, so they don’t depart any stop ahead of the published time. In spring, the same trains simply become an hour late.
The mirror image in spring
The spring change creates the opposite problem: an hour that never happens. On March 14, 2027, US clocks jump from 1:59:59 a.m. straight to 3:00:00 a.m., so no time between 2:00 and 2:59 exists that night, and the day has only 23 hours. In the EU, the jump comes on March 28, 2027 at 1:00 a.m. UTC. The mechanics of the two seasonal offsets are covered in standard vs daylight time. For software, a time like 2:30 a.m. that night cannot be resolved by picking the right pass, because there is no pass at all; libraries either shift it forward by an hour, shift it back or reject it, and Temporal’s “compatible” default shifts it forward, so an alarm set for 2:30 a.m. goes off at 3:30 a.m. instead.









