On 2026-03-04 10:21, Paul Eggert via tz wrote:
On 2026-03-04 02:19, Philip Paeps wrote:
What's wrong with "-07"? That's what's used in other parts of the world. Why
is North America exceptional?
Inertia. For example, the earliest email standard, Internet RFC 561 (1973)[1],
coauthored by the late Ray Tomlinson (widely credited for the 1971 invention of
email![2]), was designed mostly for North America because when that RFC was
written almost all the ARPANET's nodes were in North America (there was only one
exception, in London). RFC 561 specified alphabetic abbreviations, but
unsurprisingly only for North American and the UK. A subset of those
abbreviations survive not only in the current email standard[3], but also in the
drafts for its planned successor[4].
Another example: Version 7 Unix (1979) supported only [ACEMP][DS]T + GMT (good
enough for AT&T's North American operations), and similar sets of North-
American-only or -mostly abbreviations are still hardwired into a lot of
software, including the Thunderbird email program that I'm composing this
missive on (see, e.g., [5]).
Unfortunately alphabetic abbreviations do not scale world-wide. If we had to do
it over again we'd surely stick to numeric abbreviations as that's simpler and
cleaner. But that ship sailed long ago.
It'd be a stretch to change America/Edmonton, America/Whitehorse, America/
Los_Angeles, etc. to use numeric abbreviations by default - rightly or wrongly,
too many programs and people would object. And it'd be pretty strange if
America/Vancouver used numeric abbreviations even though all its neighbors used
alphabetic. Although we could add an option to zic to always generate numeric
abbreviations, for people who prefer that, that's not likely to become the
default any time soon.
Chris Walton's recent email[6] lists reasons to prefer the alphabetic
abbreviation "MST" over the alternatives, and that's the direction I'm leaning
as well.
[1]: https://datatracker.ietf.org/doc/html/rfc561
[2]: https://www.nytimes.com/2016/03/08/technology/raymond-tomlinson-email-
obituary.html
[3]: https://datatracker.ietf.org/doc/html/rfc5322
[4]: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/
[5]: https://github.com/mozilla/releases-comm-central/
blob/7913b03ecb5d21754eaa821b61ed0909ba9dbbbe/mailnews/mime/jsmime/jsmime.mjs#L1374
[6]: https://lists.iana.org/hyperkitty/list/[email protected]/
message/7Q52N6O2OJSIESKKWV7UKZ6TXYDJJXUQ/
I suspect that is the direction that will be taken by the NRC also for Canada's
offical times, which prefer using standard time zones in winter, and daylight
time zones in summer, so from federal and interprovincial guidance perspectives,
BC will follow MST in winter, and continue to follow PDT in summer
Canada > National Research Council > Certifications, evaluations and standards >
Canada's official time
https://nrc.canada.ca/en/certifications-evaluations-standards/canadas-official-time/time-zones-daylight-saving-time
(fr-CA: Fuseaux horaires d'Heure normale en hiver Heure Normale des Rocheuses
HNR, et Fuseaux horaires d'Heure avancée en été Heure Avancée du Pacifique HAP).
https://nrc.canada.ca/fr/certifications-evaluations-normes/heure-officielle-canada/fuseaux-horaires-lheure-avancee
But we may have to wait a while to see the NRC and/or federal government web
site consult with the BC government and make those updates.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
