Two Devices Show the Same Meeting an Hour Apart After the Clock Change

A recurring meeting reads 9:00 a.m. on a laptop and 10:00 a.m. on a phone. Both devices are set to the same city. Nothing was edited. The discrepancy is almost always one of two things: the two devices are working from different versions of the same time zone rule set, or the calendar entry was saved without a zone identifier and is being displayed against a fixed offset that no longer matches reality.

Work the layers in order, from the one that is cheapest to check to the one that requires editing data.

Start Here: Force Each Layer to Re-read the Rules

1. Install pending operating system updates on the device that shows the wrong hour. Time zone rules arrive as ordinary system updates, not as a separate download. On Windows, Microsoft states that it "publishes updates through Windows Update (WU)" and that "standalone DST updates are no longer available. Please use the current monthly rollup for your version of Windows."
2. Restart after the update installs. Long-running processes read the rule set once and hold it.
3. Confirm the device's own zone, not just its clock. On Windows 11: Start > Settings > Time & language > Date & time. The relevant switches on that page are Set time automatically, Set time zone automatically, and Adjust for daylight saving time automatically.
4. Open the disputed entry and look for a time zone field on the entry itself. In Google Calendar the event's zone is separate from the calendar's zone, and both are separate from the device's zone.
5. Compare against a device that displays the entry correctly. The one that disagrees is the one running stale rules or holding a frozen offset.

Steps 1 through 3 resolve the common case. Steps 4 and 5 are for the entry that stays wrong on a fully updated device.

Why the Two Devices Disagree by Exactly One Hour

Civil time rules are not built into each app. They come from a shared upstream data set, the IANA Time Zone Database, usually shortened to tzdb or zoneinfo. IANA describes it as "code and data that represent the history of local time for many representative locations worldwide," and is explicit about how it reaches ordinary devices: "End users typically receive updates to this data through their software and operating system vendors."

That sentence is the whole problem in miniature. A government changes a rule, IANA publishes a release, and then every vendor picks that release up on its own schedule. Until all of them have, two devices can hold two different answers to the same question, and neither is malfunctioning.

Permanent Daylight Saving Time Is Not the Explanation

One belief worth clearing away before troubleshooting further: the United States has not moved to year-round daylight time. Bills proposing it have been introduced repeatedly and none has taken effect. The National Institute of Standards and Technology states the rule still in force — daylight saving time "begins on the second Sunday of March (at 2 a.m. the local time time skips ahead to 3 a.m.)" and ends "the first Sunday of November (at 2 a.m. the local time becomes 1 a.m.)" — and gives the current year's dates directly: for 2026, "daylight saving time is in effect from March 8 at 2 a.m. (local time) to November 1 at 2 a.m."

Those dates come from the Energy Policy Act of 2005, which NIST credits with having "extended the length of DST in the interest of reducing energy consumption." Authority over the schedule sits with the Department of Transportation rather than NIST, and under the Uniform Time Act, as amended, states may exempt themselves from observing daylight time by state law. The Department of Transportation lists the jurisdictions that do not observe it: Hawaii, American Samoa, Guam, the Northern Mariana Islands, Puerto Rico, the Virgin Islands, and most of Arizona.

This matters for diagnosis because a device showing an unexpected hour in early November is behaving correctly if it applied the fall-back transition and the other device did not. The bug is the mismatch, not the transition.

The Difference Between an Entry That Moves and One That Doesn't

Once both devices hold the same rules and still disagree, the problem has moved into the saved data. A calendar entry can record a start time in two broadly different ways: anchored to a named zone, or anchored to a fixed distance from UTC.

An entry that carries a zone identifier is re-evaluated whenever the rules for that zone change, so its local start time holds steady. An entry that carries only a frozen offset is not re-evaluated, because there is nothing left to look up — the offset is the answer. When the underlying rule changes, that entry starts displaying an hour away from where it was intended.

Windows: Read Back the Rules the Machine Is Using

Windows ships a command that reports the zone the system has selected, which is more reliable than reading the clock and inferring. The documented syntax is:

tzutil [/?] [/g] [/s <timezoneID>[_dstoff]] [/l]

• tzutil /g displays the current time zone ID.
• tzutil /l lists all valid time zone IDs and display names.
• tzutil /s "Pacific Standard time" sets the zone. The value must be surrounded by quotes.
• The _dstoff suffix — as in tzutil /s "Pacific Standard time_dstoff" — sets the zone and disables daylight saving adjustments for it, where applicable.
• An exit code of 0 indicates the command completed successfully.

Two practical uses. First, run tzutil /g on both machines and compare the returned IDs; identical city names in the interface do not guarantee identical IDs. Second, if one machine was ever configured with a _dstoff variant, it will hold standard time year-round and sit exactly one hour away from its neighbours for the whole daylight period. That is a configuration state, not a fault, and it will not correct itself through updates.

Google Calendar: Three Zone Settings, Not One

Google documents that the service "uses Coordinated Universal Time (UTC) to help avoid issues with daylight saving time," and that "when events are created, they're converted into UTC, but you'll always see them in your local time." Display therefore depends on which zone each layer believes is in play, and there are three distinct places to set one:

• Account level: Settings > Settings > Time zone > Primary time zone, then search and select.
• Individual calendar: in the sidebar calendar list, hover over the calendar, then More > Settings and sharing > Time zone.
• Individual event: open the event, choose Edit, then select Time zone next to the event time. Separate start and end time zones can be set where needed.

Two constraints are worth knowing before spending time on this. Only calendar owners can modify time zone settings, so a shared calendar showing the wrong hour may not be fixable from the account that noticed the problem. And Google states the limitation plainly: "events in the past years or future might not reflect daylight saving time changes. It might be incorrectly displayed."

That last sentence is the vendor confirming the failure mode. A far-future recurring entry displaying an unexpected hour is a known behaviour, not evidence of a corrupted calendar.

Real Rule Changes Landing During 2026

The abstract case has concrete instances this year, and they are useful for testing whether a device is current. Per the tzdb release notes:

• Release 2026b (2026-04-22): "British Columbia moved to permanent -07 on 2026-03-09." The notes add that its "2026-03-08 spring forward was its last foreseeable clock change."
• Release 2026c (2026-07-08): "Alberta moved to permanent -06 on 2026-06-18," modelled with its traditional abbreviation CST.
• Also in 2026c: "Morocco plans to move back to permanent UTC, without daylight saving time transitions, on 2026-09-20 at 02:00. This also affects Western Sahara."

There is a wrinkle in the British Columbia and Alberta entries that explains otherwise baffling display behaviour. The maintainers note that although the Alberta change "legally took place on 2026-06-18," they "temporarily model the change to occur on 2026-11-01 at 02:00 instead," matching the same treatment given British Columbia in 2026b. The stated reason is that it "works around a limitation in CLDR 48.1 (2026-01-08)," and the notes describe it as a "temporary hack" planned for removal "after CLDR is fixed."

The consequence: for a meeting anchored to a British Columbia or Alberta zone, a device on an older data set, a device on a newer one, and a device whose calendar service applies the modelled date can each land on a different hour — and the modelled date is the same 2 a.m. on November 1 when United States clocks fall back. Two unrelated changes converging on one timestamp is precisely the condition that makes a one-hour split look inexplicable.

What Vendor Documentation Does Not Answer

Several questions come up constantly in this diagnosis and have no published answer, which is worth stating rather than guessing at:

• Which tzdb release a given OS build contains. Vendors do not map release versions to build numbers in user-facing release notes. The practical substitute is behavioural: check whether a device reflects a known recent change, such as the Alberta or Morocco entries above.
• Whether a particular app reads system rules or carries its own copy. Most applications do not document this. Where an app displays a time that disagrees with the operating system clock on the same device, a bundled copy is the likely explanation, but it is an inference rather than a documented fact.
• The exact iOS Settings path. Apple's iPhone User Guide page for changing the date and time is script-rendered and its steps could not be retrieved as text for verification here. What Apple's own page description states is that "the date and time on the iPhone are set automatically based on your location, but you can change the time zone manually." Anyone quoting a deeper menu path should confirm it against the guide on the device's own iOS version, since the layout has changed across releases.

When This Doesn't Apply

This frame explains a discrepancy of exactly one hour, or of a whole number of hours, between devices or between viewers of the same entry. It does not apply in these cases:

• The gap is minutes, not hours. That is clock synchronisation, not zone rules. On Windows, the relevant control is Set time automatically on the same Date & time page, alongside the manual Change button next to Set the date and time.
• Only one entry is wrong and everything else is correct. Rule changes affect every entry anchored to the affected zone. A single misplaced item is more likely to have been created while a device or account was set to a different zone.
• The device is in a jurisdiction that does not observe daylight time. In Hawaii, American Samoa, Guam, the Northern Mariana Islands, Puerto Rico, the Virgin Islands, and most of Arizona, no seasonal transition occurs, so a shift that appears in March or November originates elsewhere — typically in the zone the other participant is using.
• The zone was deliberately configured without daylight adjustment. A Windows machine set with the _dstoff suffix will differ by an hour for the entire daylight period by design.
• An all-day entry appears on the wrong date. All-day items are handled differently from timed items and shifting a zone setting will not reliably correct them.

The general principle holds across all of these: a time that looks wrong is usually a time being interpreted against a different set of rules than the one that created it. Establish which rule set each layer is using before editing any data, because editing an entry to make it look right on one device tends to make it wrong on every other one.