A Future Time in Your Note Needs Its Time-Zone Name

A Calgary hairdresser opened his booking software in September 2026 and found that every appointment he had pre-booked from November through March had shifted back an hour.¹ He estimates eight out of ten of his clients were affected.¹ The software had stored those future times as UTC under last year's rules. Alberta changed its rules. The UTC values are now one hour wrong.

The fix is not complicated. For a future local event, write the local wall time you intend plus the IANA time-zone name: 2026-11-15T09:00-06:00[America/Edmonton]. That format is defined by RFC 9557 (April 2024). If the offset and the zone name disagree after a rule change, the disagreement is visible — you can detect the mismatch instead of experiencing it as a silently wrong calendar entry.²

The problem in concrete terms

When government rules change, any future time stored as UTC is converted back using those new rules. If the rules have changed between storage and retrieval, the reconverted local time is wrong. Storing the wall time and the zone name preserves what you actually meant — and a mismatch between the stored offset and the current rules for that zone becomes detectable rather than silent.

Five jurisdictions changed their clocks in 2026. The IANA time zone database — the database that every operating system, programming runtime, and calendar service consults — shipped five releases in 2026 (2026a through 2026e), four of them carrying rule changes:³

• 2026b (2026-04-22): British Columbia moved to permanent −07:00 from 2026-03-09.³
• 2026c (2026-07-08): Alberta moved to permanent −06:00 from 2026-06-18. Morocco moved to permanent +00:00 from 2026-09-20.³
• 2026d (2026-09-11): Canada's Northwest Territories moved to permanent −06:00 from 2026-08-21.³
• 2026e (2026-09-29): Manitoba moves to permanent −05:00 from 2026-10-31.³

This is not unusual volume. Counting from the tzdb NEWS file headers, the database has shipped an average of roughly 5.4 releases per year since 2015 — ranging from two in 2024 to ten in 2016.³ Rule changes are the normal way things work. Jon Skeet put it plainly in 2019: "The larger point is that time zone rules change, and that applications should expect that they will change. This isn't a corner case, it's the normal way things work."⁴

The Alberta calendar failure was not a software bug in the traditional sense. It was a correct implementation of the wrong rules. Booking software that had not yet received the tzdb update rendered those stored UTC values into the old local time.¹ A University of Alberta professor quoted by CBC advised businesses to contact their software providers and ask them to push out an update as soon as possible.¹

If you are reading this before 2026-11-01: Alberta, the Northwest Territories, and Manitoba do not fall back on that date. Any future time stored for those jurisdictions under the assumption of a fall-back will be one hour off from that date forward.

The naive approach — and why it fails for future events

"Store everything in UTC" is correct for past events and logs. It is wrong for future local events because it bakes today's rules into a single number. When rules change, the UTC value is still a correct absolute instant — but converting it back to local time uses the new rules and produces a different wall clock than the one you intended.

The distinction matters. Jon Skeet's 2019 post on this question is explicit: "For machine-generated timestamps (e.g. recording when an event happened in a log file) it's entirely reasonable to store UTC — no loss of information, and you can always convert to the relevant local time afterwards."⁴ That is correct because past events are fixed instants. The conversion to local time is cosmetic.

A dentist appointment at 09:00 next March is different. The intention is not a UTC instant — it is "the moment when the wall clock in Edmonton reads 09:00 on that day." Skeet calls this Option 3: "preserve local time, using UTC as derived data to be recomputed."⁴ Compute the UTC equivalent from the wall time and current rules when you need it. Do not store it as the canonical value.

Research on real-world datetime bugs confirms this is where failures concentrate. A 2025 Distinguished Paper from the Mining Software Repositories conference studied 151 datetime-related bugs across major open-source projects and found that approximately 53.6% "are associated with time zones" — "time-zone-related mistakes are the largest contributing factor."⁵ The same paper notes that "one may consider performing all computations in UTC; however this cannot be the solution either."⁵

RFC 9557 is precise about the failure mode: "programs MUST NOT copy the UTC offset from a timestamp into an offset time zone in order to satisfy another program that requires a time zone suffix in its input. Doing this will improperly assert that the UTC offset of timestamps in that location will never change."²

The format: wall time plus zone name

RFC 9557 defines the form: ISO 8601 date-time, the UTC offset you expect, and the IANA zone name in square brackets. A future Calgary meeting at 9 a.m. on November 15 is 2026-11-15T09:00-06:00[America/Edmonton]. If the rules for America/Edmonton change between now and then, the stored offset (−06:00) will disagree with the zone's new rules — a detectable inconsistency rather than a silent wrong conversion.

The RFC states that this combination "may be sufficient to detect an inconsistency between the intention and the actual information in the timestamp, e.g., when the IANA Time Zone Database is updated due to political decisions."² The zone name is the key: it names what the author intended. The offset is the author's expectation of what that zone maps to today. Any divergence is now visible.

One clarification about what RFC 9557 does and does not do: §1.1 explicitly states that IXDTF "does not address the problem of a future time given as a local time in some specified time zone."² IXDTF is a fixed-instant format. The zone-name suffix adds detection capability — it is not a guarantee that the moment is immune to change. RFC 9557 §3.4 puts the practical recommendation directly: "far-future meeting times should generally specify both an offset and a time zone identifier such as [America/Los_Angeles]. This is because the time zone definition can potentially change between the meeting's scheduling and its occurrence."²

Do not use the zone abbreviation. The tzdb theory page notes that abbreviations like "CST" are "ambiguous in practice."⁶ Alberta's government uses "ABT" for Alberta Time.⁷ The tzdb uses "MST" for the same zone post-2026c. Neither abbreviation is a stable identifier. America/Edmonton is — it names the same zone regardless of what abbreviation that zone's rules happen to produce in a given period.

The TC39 Temporal proposal, which brings this behavior to JavaScript, documents that "Time zone definitions can change due to governmental action at any time."⁸ Its ZonedDateTime type stores both the instant and the zone. When an offset conflict is detected, the default behavior is 'reject' — because, as the docs note, "there is no obvious default solution."⁸

The following diagram shows when UTC is the right choice and when the RFC 9557 form is more durable. UTC correctly preserves past events and logs as fixed instants. For a future local event, the wall time plus zone name keeps the intent readable and any rule-change mismatch detectable.

flowchart TD
    A["Time to record"] --> B{"Past event\nor log?"}
    B -->|Yes| C["Store UTC\n(fixed instant;\nrules irrelevant)"]
    B -->|"No — future\nlocal event"| D["Store wall time\n+ IANA zone name\nRFC 9557 form"]
    D --> E{"Rules change\nbefore the event?"}
    E -->|No| F["Stored offset\nmatches zone\n→ correct conversion"]
    E -->|Yes| G["Stored offset\nvs zone disagree\n→ detectable mismatch"]

Figure: Storage decision for times in notes. UTC is appropriate for past events and logs — the instant is fixed and local-time conversion is cosmetic. For a future local event, the wall time plus IANA zone name (RFC 9557 form) preserves the intended wall-clock reading and surfaces any rule-change as a visible offset-vs-zone mismatch rather than a silent wrong conversion.

A plain-text note can carry the full string without any special tooling:

Meeting with Priya
2026-11-15T09:00-06:00[America/Edmonton]

Nothing about this format requires a proprietary app to store or read. Any tool that parses RFC 9557 or ISO 8601-extended text will understand it. The zone name remains readable and checkable by hand even if every piece of software in the chain is replaced.

Verifying the rules your tools are actually using

Before trusting a future-time conversion, verify which version of the tzdb the tool has. One shell command shows whether America/Edmonton has any 2026 transitions. No output means the permanent −06:00 rule is in effect. A transition line means the local copy has not yet received the 2026c update.

# Check whether America/Edmonton has any 2026 transitions
# No output → permanent offset, no fall-back scheduled
zdump -v America/Edmonton | grep 2026

Under tzdb 2026c or later, this command produces no output for America/Edmonton — the zone is permanently −06:00 with no transition. Under an older tzdb, you will see a November transition line.

# Confirm the UTC equivalent for a specific future local date
TZ=America/Edmonton date -d "2026-11-15 09:00" --utc
# → Sun Nov 15 15:00:00 UTC 2026  (UTC-6, post-2026c)

Compare that with the old-rules output, emulated using the POSIX MST7MDT zone (which still observes fall-back):

TZ=MST7MDT date -d "2026-11-15 09:00" --utc
# → Sun Nov 15 16:00:00 UTC 2026  (UTC-7 after fall-back)
# One hour off — stored UTC(old) renders 10:00 in Calgary, not 09:00

In Python, using the standard library zoneinfo module (Python 3.9+):

from zoneinfo import ZoneInfo
from datetime import datetime

dt = datetime(2026, 11, 15, 9, 0, tzinfo=ZoneInfo("America/Edmonton"))
print(dt.utcoffset(), dt.strftime("%Z"))
# → -1 day, 18:00:00  MST   (offset = UTC-6, not UTC-7)

The zoneinfo module reads from the system tzdata package. To verify the installed version:

import importlib.metadata
print(importlib.metadata.version("tzdata"))
# e.g. → 2026.2   (corresponds to tzdb 2026c)

Note: strftime("%Z") for America/Edmonton post-2026c returns "MST" — the tzdb abbreviation, not Alberta's official "ABT". The offset (-06:00) and the zone identifier (America/Edmonton) are correct; the display label is a tzdb convention.

A caveat on the tzdb's own modelling. The 2026b NEWS entry notes that the BC change "legally took place on 2026-03-09" but is modelled "to occur on 2026-11-01 at 02:00 instead. This works around a limitation in CLDR 48.1."³ The same CLDR-compatibility modelling applies to the Alberta, NWT, and Manitoba entries. The practical effect for any date after 2026-11-01 is the same; the database records the change with a CLDR workaround. Older devices that never receive the update may continue to apply the fall-back indefinitely.⁹

Why your AI gives the old answer

Language models answer time-zone conversion questions from their training data, not from a live tzdb. One benchmark found all 19 frontier models tested still gave the old answer for a Calgary-to-Toronto conversion under current rules. Even with a time-zone lookup tool available, one benchmark found that 8 of 16 models returned the wrong answer. Models do not caveat that their tz rules may be outdated.

The problem is structural. A 2024 Outstanding Paper from the Conference on Language Models studied models' temporal self-knowledge and found that "effective cutoffs often differ from reported cutoffs" — a model's actual knowledge of recent events routinely trails its nominal training date.¹⁰

One practitioner benchmark (19 models, temperature 0, no tools, answer key derived from Python zoneinfo under tzdb 2026d) asked each model: "It is 9 a.m. here on November 15. What time is that in Toronto?" — posed from a Calgary context.¹¹ One benchmark found that all 19 said 11:00. The correct answer under current rules is 10:00.¹¹ One benchmark found that not one of the 19 offered any caveat that its time-zone information might be stale.¹¹

When the same benchmark gave 16 of the models access to a time-zone lookup tool, one benchmark found that 8 of the 16 still said 11:00 — the tool was available but not consulted.¹¹

This is one practitioner's result from a single dev.to post, not a peer-reviewed survey. Treat it as illustration. The peer-reviewed anchor for why this class of error matters at scale is the 2025 MSR Distinguished Paper: 53.6% of datetime bugs in production software trace to time zones.⁵ An AI answering from stale rules adds a second source of failure on top of that existing concentration.

For any future-time conversion that matters, use zdump or Python zoneinfo with a known-current tzdata version rather than a model's in-context answer. The model does not know what tzdb version is current. It knows what was current when its training data was collected.

Trade-offs and what this approach does not do

The RFC 9557 string format solves detection, not automatic correction. It tells you there is a conflict between the stored offset and the current rules. It does not tell you which to believe. That judgment is yours. Several other limits apply.

RFC 9557 §1.1 is explicit: IXDTF "does not address the problem of a future time given as a local time in some specified time zone."² It addresses a different, narrower question — how to represent a fixed instant with enough zone context to detect inconsistencies. What to do when an inconsistency is detected is a policy question, not a format question.

Devices that never update. The tzdb maintainers note that "Older devices may never be updated" with new rules.⁹ A device running a tzdb from 2025 will still apply the Alberta fall-back on 2026-11-01. If a meeting is on that device's calendar, it will move. The RFC 9557 string in a note does not fix the device.

The "at least a year" ask is routinely violated. The tzdb tz-link page asks that "any rule change should be promulgated at least a year before it affects how clocks operate."⁹ Manitoba's government announced its 2026-11-01 change on 2026-09-17 — 45 days' notice.¹² That is not a criticism of Manitoba; it reflects how these decisions are actually made. The tzdb maintainers know this and update within weeks regardless.

Plain text is not a calendar. Writing 2026-11-15T09:00-06:00[America/Edmonton] in a note is not a calendar event. No alarm fires. The format is honest, portable, and checkable by hand — but acting on it still requires a step from you or a tool you have configured to parse it.

An earlier post in this series, A Calendar File Is Just Plain Text, covers the .ics format and mentions UTC as a storage convention for calendar events.¹³ That advice is correct for past events and for events in jurisdictions whose rules are stable. This post refines it for future local events in jurisdictions where rules may change: the local wall time plus the zone name is the more durable form.

Frequently Asked Questions

Should I store future times in UTC?

UTC is the right choice for logs and past events — fixed instants where local-time conversion is cosmetic. For future local events, UTC bakes today's time-zone rules into the stored value. When those rules change, conversion back to local time uses the new rules and returns a different wall time than intended. Store the wall time and the IANA zone name instead; derive UTC when you need it.

How do I write a date with a time zone in my notes?

RFC 9557 form: 2026-11-15T09:00-06:00[America/Edmonton]. ISO 8601 date-time, the UTC offset you expect, and the IANA zone name in brackets. If the rules change, the offset and zone name will disagree — a visible signal rather than a silent wrong conversion.

Why did my appointments move an hour after the Alberta change?

Alberta moved to permanent UTC-6 from 2026-06-18 (tzdb 2026c, published 2026-07-08). Software that had stored future appointments as UTC under the previous rules — which included a fall-back to UTC-7 in November — rendered them one hour later than intended under the new permanent UTC-6 offset.

Can ChatGPT convert time zones correctly?

One benchmark found all 19 frontier models tested gave the old pre-2026c answer for a Calgary-to-Toronto conversion. Models answer from training data, not from a live tzdb. Use zdump or Python zoneinfo with a current tzdata install for any conversion that matters.

What is RFC 9557?

RFC 9557 (April 2024) is an IETF standard that extends ISO 8601 date-time strings with an optional time-zone identifier in brackets. It says far-future meeting times should carry both an offset and a zone identifier "because the time zone definition can potentially change between the meeting's scheduling and its occurrence." It is a detection format, not a correction format.

How often does the time zone database change?

The IANA tzdb has averaged roughly 5.4 releases per year since 2015, ranging from two in 2024 to ten in 2016. In 2026 it shipped five releases as of 2026-09-29, four of them carrying clock-rule changes. Rule changes are routine; 2026 is not an anomaly.

What is the correct IANA zone name for Alberta?

America/Edmonton. Alberta's government uses the abbreviation "ABT" for Alberta Time; the tzdb uses "MST" for the same zone. Neither abbreviation is a stable identifier. America/Edmonton names the zone regardless of which abbreviation the current rules generate.

A time written in plain text survives every app migration, every sync failure, every format change. The RFC 9557 string 2026-11-15T09:00-06:00[America/Edmonton] is readable by any editor, verifiable by any shell, and honest about what it does not guarantee. The only thing it cannot do is update itself when governments decide to change the clocks.

A note in open Markdown text can carry a fully explicit, verifiable timestamp — nothing about the format requires a proprietary app to stay legible or checkable. mnmnote.com

References