B. C. Gov News: "Adopting permanent daylight saving time: ‘Spring forward’ on March 8 will be the last time change, ending twice-yearly clock changes." https://news.gov.bc.ca/releases/2026AG0013-000209 @dashdashado
CBC, CTV, and Global are reporting the same: https://www.cbc.ca/news/canada/british-columbia/b-c-adopting-year-round-dayl... https://www.ctvnews.ca/vancouver/article/bc-moving-to-permanent-daylight-tim... https://globalnews.ca/news/11713160/bc-david-eby-niki-sharma-announcement-ti... Video of the press conference, held at ~12:30 local (UTC−8) Monday by BC Premier David Eby, is available here: https://www.youtube.com/watch?v=upEasdN8tVE It appears this action represents the activation/enforcement of a 2019 "Interpretation Amendment Act", so it seems the press release from the BC Attorney General may be all the official documentation we'll have to go on for a while. It simply says "Regulation will bring the amendments into effect after Sunday, March 8, 2026." As Winfield, BC's *Lake Country Calendar* reports it, the 2019 bill "allows the changes to be implemented without any further legislation either way, and the government has opted to stop waiting." https://lakecountrycalendar.com/2026/03/02/eby-announces-permanent-move-to-d... Confusingly, per CBC, "B.C.'s new time zone will be called 'Pacific Time,' according to the province." By contrast, we already have a longstanding practice of using "MST" in our data for yearround UTC−7 in Yukon as well as for border regions such as America/Dawson_Creek and America/Fort_Nelson. So, although there has already been some breakdown in nomenclature from legacy zones like PST8PDT, that is now brought to a more populous province of ~5.7 million. (For what it's worth, CBC News has been recently using "YST" for Yukon time in their online simulcasts to YouTube.) The press release points to "[r]ecent actions from the U.S. hav[ing] shifted how B.C. approaches decisions that merit alignment, including on time zones", so the difference in nomenclature between this new "Canadian Pacific Time" and "US Pacific Time" — while likely to cause cross-border confusion next winter — is likely an intentional part of "the province's broader plans to move away from interdependence with the U.S." Although the press release correctly points out that "[n]eighbour jurisdictions like Washington, Oregon and California are all in the process of creating or enacting similar legislation", it does not mention that a similar shift to yearround UTC−7 for those states would be dependent on action from either the US Congress or Department of Transportation. -- Tim Parenti On Mon, 2 Mar 2026 at 15:59, Arthur Olson via tz <tz@iana.org> wrote:
B. C. Gov News: "Adopting permanent daylight saving time: ‘Spring forward’ on March 8 will be the last time change, ending twice-yearly clock changes."
https://news.gov.bc.ca/releases/2026AG0013-000209
@dashdashado
The relevant statutes that this OIC brings into force are pretty bare-bones (see full legislation here: https://www.bclaws.gov.bc.ca/civix/document/id/bills/billsprevious/4th41st:g...) 26 (1) In this section, "Pacific Time" means 7 hours behind Coordinated Universal Time (UTC). (2) A reference to time in British Columbia is a reference to Pacific Time. --and-- 6 This Act comes into force by regulation of the Lieutenant Governor in Council. There is also a few consequential amendments noted in the Act that are effected as a result of this OIC. Namely the Election Act and the Vancouver Charter.
daviscarlson00@gmail.com wrote:
The relevant statutes that this OIC brings into force are pretty bare-bones (see full legislation here: https://www.bclaws.gov.bc.ca/civix/document/id/bills/billsprevious/4th41st:g...)
26 (1) In this section, "Pacific Time" means 7 hours behind Coordinated Universal Time (UTC). (2) A reference to time in British Columbia is a reference to Pacific Time. --and-- 6 This Act comes into force by regulation of the Lieutenant Governor in Council.
There is also a few consequential amendments noted in the Act that are effected as a result of this OIC. Namely the Election Act and the Vancouver Charter.
Re-posting the link for the official, signed, OIC that Michael sent earlier as their message was not showing up correctly in the web version of the list archive. https://www.bclaws.gov.bc.ca/civix/document/id/oic/oic_cur/0063_2026.
Of course "Pacific Standard Time" (not to be confused with anybody's local definition of "Pacific Time") will remain entrenched in the Federal interpretation act as being GMT-8.... just like "Yukon Standard Time" continues to be entrenched in the Federal interpretation as being GMT-9. From https://laws-lois.justice.gc.ca/eng/acts/i-21/:
standard time, except as otherwise provided by any proclamation of the Governor in Council that may be issued for the purposes of this definition in relation to any province or territory or any part thereof, means ... (f) in relation to the Province of British Columbia, Pacific standard time, being eight hours behind Greenwich time, and (g) in relation to Yukon, Yukon standard time, being nine hours behind Greenwich time; (heure normale)
-chris On Mon, Mar 2, 2026 at 4:41 PM Tim Parenti via tz <tz@iana.org> wrote:
CBC, CTV, and Global are reporting the same:
https://www.cbc.ca/news/canada/british-columbia/b-c-adopting-year-round-dayl...
https://www.ctvnews.ca/vancouver/article/bc-moving-to-permanent-daylight-tim...
https://globalnews.ca/news/11713160/bc-david-eby-niki-sharma-announcement-ti...
Video of the press conference, held at ~12:30 local (UTC−8) Monday by BC Premier David Eby, is available here: https://www.youtube.com/watch?v=upEasdN8tVE
It appears this action represents the activation/enforcement of a 2019 "Interpretation Amendment Act", so it seems the press release from the BC Attorney General may be all the official documentation we'll have to go on for a while. It simply says "Regulation will bring the amendments into effect after Sunday, March 8, 2026." As Winfield, BC's *Lake Country Calendar* reports it, the 2019 bill "allows the changes to be implemented without any further legislation either way, and the government has opted to stop waiting."
https://lakecountrycalendar.com/2026/03/02/eby-announces-permanent-move-to-d...
Confusingly, per CBC, "B.C.'s new time zone will be called 'Pacific Time,' according to the province." By contrast, we already have a longstanding practice of using "MST" in our data for yearround UTC−7 in Yukon as well as for border regions such as America/Dawson_Creek and America/Fort_Nelson. So, although there has already been some breakdown in nomenclature from legacy zones like PST8PDT, that is now brought to a more populous province of ~5.7 million. (For what it's worth, CBC News has been recently using "YST" for Yukon time in their online simulcasts to YouTube.)
The press release points to "[r]ecent actions from the U.S. hav[ing] shifted how B.C. approaches decisions that merit alignment, including on time zones", so the difference in nomenclature between this new "Canadian Pacific Time" and "US Pacific Time" — while likely to cause cross-border confusion next winter — is likely an intentional part of "the province's broader plans to move away from interdependence with the U.S." Although the press release correctly points out that "[n]eighbour jurisdictions like Washington, Oregon and California are all in the process of creating or enacting similar legislation", it does not mention that a similar shift to yearround UTC−7 for those states would be dependent on action from either the US Congress or Department of Transportation.
-- Tim Parenti
On Mon, 2 Mar 2026 at 15:59, Arthur Olson via tz <tz@iana.org> wrote:
B. C. Gov News: "Adopting permanent daylight saving time: ‘Spring forward’ on March 8 will be the last time change, ending twice-yearly clock changes."
https://news.gov.bc.ca/releases/2026AG0013-000209
@dashdashado
On 2026-03-02 14:40, Tim Parenti via tz wrote:
CBC, CTV, and Global are reporting the same: https://www.cbc.ca/news/canada/british-columbia/b-c-adopting-year-round- daylight-time-9.7111657 <https://www.cbc.ca/news/canada/british-columbia/b-c- adopting-year-round-daylight-time-9.7111657> https://www.ctvnews.ca/vancouver/article/bc-moving-to-permanent-daylight-tim... <https://www.ctvnews.ca/vancouver/article/bc-moving-to-permanent-daylight-tim...> https://globalnews.ca/news/11713160/bc-david-eby-niki-sharma-announcement-ti... <https://globalnews.ca/news/11713160/bc-david-eby-niki-sharma-announcement-ti...>
Video of the press conference, held at ~12:30 local (UTC−8) Monday by BC Premier David Eby, is available here: https://www.youtube.com/watch?v=upEasdN8tVE <https://www.youtube.com/watch? v=upEasdN8tVE>
It appears this action represents the activation/enforcement of a 2019 "Interpretation Amendment Act", so it seems the press release from the BC Attorney General may be all the official documentation we'll have to go on for a while. It simply says "Regulation will bring the amendments into effect after Sunday, March 8, 2026." As Winfield, BC's /Lake Country Calendar/ reports it, the 2019 bill "allows the changes to be implemented without any further legislation either way, and the government has opted to stop waiting." https://lakecountrycalendar.com/2026/03/02/eby-announces-permanent-move-to- daylight-saving-time-end-of-clock-changes/ <https:// lakecountrycalendar.com/2026/03/02/eby-announces-permanent-move-to-daylight- saving-time-end-of-clock-changes/>
Confusingly, per CBC, "B.C.'s new time zone will be called 'Pacific Time,' according to the province." By contrast, we already have a longstanding practice of using "MST" in our data for yearround UTC−7 in Yukon as well as for border regions such as America/Dawson_Creek and America/Fort_Nelson. So, although there has already been some breakdown in nomenclature from legacy zones like PST8PDT, that is now brought to a more populous province of ~5.7 million. (For what it's worth, CBC News has been recently using "YST" for Yukon time in their online simulcasts to YouTube.)
The press release points to "[r]ecent actions from the U.S. hav[ing] shifted how B.C. approaches decisions that merit alignment, including on time zones", so the difference in nomenclature between this new "Canadian Pacific Time" and "US Pacific Time" — while likely to cause cross-border confusion next winter — is likely an intentional part of "the province's broader plans to move away from interdependence with the U.S." Although the press release correctly points out that "[n]eighbour jurisdictions like Washington, Oregon and California are all in the process of creating or enacting similar legislation", it does not mention that a similar shift to yearround UTC−7 for those states would be dependent on action from either the US Congress or Department of Transportation.
Seems inadvisable given that natural solar times are ~UTC-9 @ 138W (N coast near AK) to ~UTC-0730 @ 114W (S border with AB). Might want to label this zone BC Pacific Time rather than Canadian, or just BC Time BCT, as Alberta, for example, could decide to switch to its "natural" solar time zone year round UTC-8 (or UTC-0730) and call it (AB) Pacific Time. (UK, Canada, and so on tend not to use periods in abbreviations, acronyms, or contractions, and I think I have seen some guidelines or regulations around that). Provinces in Canada are the sole arbiters of time zone regulations and labels. But Quebec, and/or New Brunswick, and/or the Federal Government represented by Canadian national standards bodies e.g. NRC, could raise issues about what they will call it in English and French to avoid confusion across or between jurisdictions, and decide to keep calling it Mountain Standard Time MST and Heure Normale des Rocheuses HNR in French, or even Yukon Standard Time YST, to avoid confusion with US time zone labels. See Canada > National Research Council > Certifications, evaluations and standards > Canada's official time https://nrc.canada.ca/en/certifications-evaluations-standards/canadas-offici... https://nrc.canada.ca/fr/certifications-evaluations-normes/heure-officielle-... Also, if you look at how late winter sunrise is in the CBC article, especially in northern latitudes (Prince Rupert 10:00), and consider the likely effects on drivers, school children, and accident rates, they would not be the first jurisdiction to have to switch back abruptly when statistics look horrendous. Along with likely economic impacts business and travel groups are raising, they might abandon or reverse their plans, if they realize those effects on their future election prospects, adding to all their other woes they hope this issue may distract from (First Nations property rights are constitutionally guaranteed; private property rights are not: BC Supreme Court ruled land titles "defective and invalid" vs First Nations possibly superior title and claims, supported by current provincial government agreements and policies!)
On Mon, 2 Mar 2026 at 15:59, Arthur Olson via tz wrote:
B. C. Gov News: "Adopting permanent daylight saving time: ‘Spring forward’ on March 8 will be the last time change, ending twice-yearly clock changes."
https://news.gov.bc.ca/releases/2026AG0013-000209 <https://news.gov.bc.ca/ releases/2026AG0013-000209>
@dashdashado -- 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
On 03.03.26 08:31, Brian Inglis via tz wrote:
Seems inadvisable given that natural solar times are ~UTC-9 @ 138W (N coast near AK) to ~UTC-0730 @ 114W (S border with AB).
That's nothing new under the sun. Just ask Spain. In Santiago de Compostela, solar mid-day is after 14:30 in summer. -- -- regards -- -- Matthias Urlichs
Thanks for the heads-up. I talked about this with Tim. Proposed patch attached. We'll need a new TZDB release soon. I see two issues with the BC change. Legally, 21 hours after the long-planned 2026-03-08 02:00 transition from PST to PDT, this change introduces a new transition from PDT to Pacific Time that alters the tm_isdst flag and likely the abbreviation but does not alter the UT offset. A 21-hour gap between two transitions is small, so initially I thought of modeling things with a single transition. However, zic and zdump work fine with a 21-hour gap so the attached proposed patch follows the letter of the law rather than simplifying it. No matter what abbreviation we use, there will be trouble. The obvious abbreviation PT does not conform to the POSIX standard or to TZDB guidelines, as it is one letter too short. The alphabetic abbreviation least likely to break existing software is "MST", but that clashes with the name "Pacific Time". The attached patch suggests some other possibilities. I asked the BC government for guidance; if they do not have a helpful suggestion I suspect "MST" will be the best of a bad lot of alphabetic abbreviations, due to software compatibility issues. In the meantime I installed into the development repository the proposed patch, which uses a "-07" placeholder that also should work but is jarring in a North American context. Comments welcome of course.
On Mon, 2 Mar 2026 at 18:01, via tz <tz@iana.org> wrote:
There is also a few consequential amendments noted in the Act that are effected as a result of this OIC. Namely the Election Act and the Vancouver Charter.
The changes to the Election Act in BC just clean up references like "Pacific Standard Time or Pacific Daylight Saving Time, as applicable". Somewhat more significant is the change to the Vancouver Charter, which repeals the section allowing the Council (essentially the provincial government's cabinet) to "prescribe a period in each year" for DST. In other words, this week's announcement is a one-way change that the Council could undertake at their option, which the recent Order in Council (OIC) effectuates. If it is to be undone at some later date, it would no longer be a matter for the Council, but would instead have to go through new legislation. On Mon, 2 Mar 2026 at 17:12, Chris Walton <crj.walton@gmail.com> wrote:
Of course "Pacific Standard Time" (not to be confused with anybody's local definition of "Pacific Time") will remain entrenched in the Federal interpretation act as being GMT-8.... just like "Yukon Standard Time" continues to be entrenched in the Federal interpretation as being GMT-9. From https://laws-lois.justice.gc.ca/eng/acts/i-21/:
In particular, the definition of "standard time" in section 35 of the federal Interpretation Act. Note that it still lists Saskatchewan as being in the Mountain time zone, despite their long-standing observance of CST. https://laws-lois.justice.gc.ca/eng/acts/I-21/page-3.html#h-279462 This also points to one potential wrinkle to be ironed out — For federal elections governed by the federal Canada Elections Act, after handling the Newfoundland and Atlantic time zones, polling times are synchronized across the Eastern, Central, and Mountain time zones, with special language handling Saskatchewan's widespread CST observance. (Of course, small exceptions abound in border communities which are the remit of Elections Canada and beyond the scope of this conversation.) After polls close in those regions at 9:30pm Eastern/7:30pm Mountain, polls close in the Pacific time zone a half-hour later at 7:00pm. And indeed, polls in BC and Yukon did just that in the April 2025 federal election. But with the new interpretation, 7:00pm "new" Pacific time, being equivalent to 7:00pm Mountain time in the winter, could potentially create a confusing scenario in which polls would close on the west coast a half-hour *before* the interior of the country. https://laws-lois.justice.gc.ca/eng/acts/e-2.01/page-11.html#h-204817 Technically, this could have affected Yukon similarly at any point since 2020, but Canada hasn't had a federal election outside of the annual DST period since 2006 so it just hasn't come up. So definitely something to potentially watch for in Ottawa. On Tue, 3 Mar 2026 at 02:32, Brian Inglis via tz <tz@iana.org> wrote:
Might want to label this zone BC Pacific Time rather than Canadian
But Quebec, and/or New Brunswick, and/or the Federal Government represented by Canadian national standards bodies e.g. NRC, could raise issues about what they will call it in English and French to avoid confusion across or between jurisdictions, and decide to keep calling it Mountain Standard Time MST and Heure Normale des Rocheuses HNR in French, or even Yukon Standard Time YST, to avoid confusion with US time zone labels.
Although the population of the affected region (the majority of BC) does outnumber those in existing "year-round MST" regions in Canada by a factor of several dozen, the population/scale is not really the key difference here. Rather, it's an issue of nomenclature: The *entirety* of what was once called the "Pacific" time zone in Canada has now been completely redefined at either local or provincial/territorial levels. There's no good way around it that won't affect developers in both Canada and the US. Ruby on Rails' ActiveSupport::TimeZone, for instance, attempts to "[l]imit the set of zones provided by TZInfo to a meaningful subset". It maps the string "Pacific Time (US & Canada)" to "America/Los_Angeles". The baked-in assumptions, once seemingly reasonable, now swiftly break down. https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html While standards bodies will undoubtedly put in their two cents on terminology, much of the public's awareness and parlance will likely be shaped by broadcast (and, to a lesser extent, print) media, and possibly even things like sports leagues. In particular, the operations of the National Hockey League (NHL) prominently straddle the US–Canadian border. Next winter, when a US national broadcaster advertises a cross-border game for "8[pm] Eastern, 5 Pacific", will a Canadian broadcaster be saying "8 Eastern, 6 Pacific", or will they use different terminology in an attempt to avoid confusion where someone reading a Canadian article stateside tunes in an hour late? On NHL's website, one can choose to view league schedules in any of the major continental time zones from Newfoundland to Pacific, including "Mountain (Arizona)" as Arizona once had a team in the league. (Though Saskatchewan, which doesn't, is not present; the all-prevalent "Your Time Zone" option covers that for those affected, I guess.) Will a separate "Pacific (British Columbia)" option be added do disambiguate from the US west coast, or will it be combined with the equivalent time in Arizona, with or without any mention of "Mountain" or "Pacific"? https://www.nhl.com/schedule On Tue, 3 Mar 2026 at 13:51, Paul Eggert via tz <tz@iana.org> wrote:
I suspect "MST" will be the best of a bad lot of alphabetic abbreviations, due to software compatibility issues.
I agree that "MST" is probably the "best of a bad lot" due in large part to the legacy concerns here and existing use in neighboring regions. Anything with a "P" begs for some sort of disambiguation, which would be clunky at best, and I'm quite wary of the more esoteric options Paul and I brainstormed which would introduce punctuation into otherwise alphabetic abbreviations. That said, I will gently remind readers that part of the reason this project asks for long leadtimes is precisely to afford us the opportunity to work out these sorts of issues *ahead* of cutting a release where possible. There is obviously much work and testing to do downstream as well, so we don't expect to wait past the early part of spring, which still leaves many months ahead of BC's planned divergence from past practice slated for 1 November 2026. In the meantime, if a more urgent change pops up elsewhere in the world necessitating a quicker release, "-07" will indeed suffice in the short-term. Hopefully some combination of official guidance and/or functional consensus can emerge quickly. If folks know anyone in Canadian media, especially those who may be involved in discussions on how this change will affect internal style guides, editorial standards, and the like, I suppose that could help us to move things along. -- Tim Parenti
I have always maintained that it is better for the members of this list to pick the time zone names because the people here are far more knowledgeable about these things than the politicians or the general public. This is the wording that was placed into the British Columbia Interpretation Amendment Act back in 2019:
Pacific Time 26 (1) In this section, “Pacific Time” means 7 hours behind Coordinated Universal Time (UTC). (2) A reference to time in British Columbia is a reference to Pacific Time.
This is the wording that was placed into the Yukon Interpretation Act in 2020:
(1) The Commissioner in Executive Council shall make regulations setting standard time. (2) Standard time shall be reckoned as the number of hours behind Greenwich Time set by regulations, and called Yukon Standard Time. (3) Despite subsection (2), if the standard time set by the Commissioner in Executive Council is the same as Pacific Standard Time, standard time shall be called Pacific Standard Time.
The BC government in 2019 made an assumption that BC, Yukon, California, Oregon, and Washington would all make the same change at the same time on the same date. Clearly that did not happen. The BC government also believed it had the authority to redefine the term *Pacific Time* without consulting its neighbors to the north and south. The Yukon government then assumed in 2020 that BC, California, Oregon, and Washington would ultimately want to keep the term *Pacific Standard Time*, even though this conflicts with the naming convention introduced by the BC government the year before. Nobody really wants to be in a situation where there are different definitions of *Pacific Time* on either side of the Canada/USA border. And given that a single contiguous time zone will span most of Yukon and BC year round, there is no reasonable excuse for both BC and Yukon governments to label it with different names. The best way to help the governments and the public is to ignore any time zone names in the legislation. We already did this for Yukon. We can do it for BC too. Thus the TZ DB should call BC's new time zone what it is: *Mountain Standard Time* (or *MST*). This name has been used since 1883 in Canada, US, & Mexico to mean UTC-7. There are already seven TZ zones (not including links) that use UTC-7 year round. The TZ database currently assigns the abbreviation *MST* for all seven of these zones. Three of these zones are already used by areas in BC and one of those three is shared with Arizona. Assigning the string "*-07*" to *America/Vancouver* would make it inconsistent with other UTC-7 zones and would make it the only North American zone using a numeric offset rather than a standard abbreviation. For the sake of internal consistency and alignment with long-standing usage of MST to mean UTC-7, I favour *MST* over "*-07*". -chris On Tue, Mar 3, 2026 at 1:51 PM Paul Eggert via tz <tz@iana.org> wrote:
Thanks for the heads-up. I talked about this with Tim. Proposed patch attached. We'll need a new TZDB release soon.
I see two issues with the BC change.
Legally, 21 hours after the long-planned 2026-03-08 02:00 transition from PST to PDT, this change introduces a new transition from PDT to Pacific Time that alters the tm_isdst flag and likely the abbreviation but does not alter the UT offset. A 21-hour gap between two transitions is small, so initially I thought of modeling things with a single transition. However, zic and zdump work fine with a 21-hour gap so the attached proposed patch follows the letter of the law rather than simplifying it.
No matter what abbreviation we use, there will be trouble. The obvious abbreviation PT does not conform to the POSIX standard or to TZDB guidelines, as it is one letter too short. The alphabetic abbreviation least likely to break existing software is "MST", but that clashes with the name "Pacific Time". The attached patch suggests some other possibilities. I asked the BC government for guidance; if they do not have a helpful suggestion I suspect "MST" will be the best of a bad lot of alphabetic abbreviations, due to software compatibility issues. In the meantime I installed into the development repository the proposed patch, which uses a "-07" placeholder that also should work but is jarring in a North American context.
Comments welcome of course.
Chris Walton wrote:
I have always maintained that it is better for the members of this list to pick the time zone names because the people here are far more knowledgeable about these things than the politicians or the general public.
That is the dream. That or governments leave legislation with something akin to "A reference to time in _place_ is a reference to _number_ hours _ahead\behind_ Coordinated Universal Time (UTC)." Though I can see where then style guides and government communications may introduce some ambiguity if the document only says "9pm". Chris Walton wrote:
Assigning the string "*-07*" to *America/Vancouver* would make it inconsistent with other UTC-7 zones and would make it the only North American zone using a numeric offset rather than a standard abbreviation.
For the sake of internal consistency and alignment with long-standing usage of MST to mean UTC-7, I favour *MST* over "*-07*".
Agreed. If the Yukon was still using the abbreviation *YST*, then I could see a [weak, but existent] case for something akin to *CPT* (Canadian Pacific Time), but given that is not the case, *MST* seems like it will cause the least headaches for British Columbian's. This move from BC has also started Alberta thinking on stopping the changing of the clocks (see https://www.cbc.ca/news/canada/calgary/smith-daylight-savings-9.7112097), so I'd hate to see a new precedent set that every province will get its own special abbreviation just because the government wrote legislation without doing thorough consultations.
On 2026-03-04 02:51:11 (+0800), Paul Eggert via tz wrote:
Thanks for the heads-up. I talked about this with Tim. Proposed patch attached. We'll need a new TZDB release soon.
I see two issues with the BC change.
Legally, 21 hours after the long-planned 2026-03-08 02:00 transition from PST to PDT, this change introduces a new transition from PDT to Pacific Time that alters the tm_isdst flag and likely the abbreviation but does not alter the UT offset. A 21-hour gap between two transitions is small, so initially I thought of modeling things with a single transition. However, zic and zdump work fine with a 21-hour gap so the attached proposed patch follows the letter of the law rather than simplifying it.
No matter what abbreviation we use, there will be trouble. The obvious abbreviation PT does not conform to the POSIX standard or to TZDB guidelines, as it is one letter too short. The alphabetic abbreviation least likely to break existing software is "MST", but that clashes with the name "Pacific Time". The attached patch suggests some other possibilities. I asked the BC government for guidance; if they do not have a helpful suggestion I suspect "MST" will be the best of a bad lot of alphabetic abbreviations, due to software compatibility issues. In the meantime I installed into the development repository the proposed patch, which uses a "-07" placeholder that also should work but is jarring in a North American context.
Comments welcome of course.
What's wrong with "-07"? That's what's used in other parts of the world. Why is North America exceptional? I would suggest that CPST -- analogous to AEST -- is probably a better choice if "-07" won't do for some reason. Philip
Another option for the name that I haven't seen discussed is "PDT". Washington, Oregon, and California, are big populations that do have ties with BC, aligning with their name for the majority of the year might be more useful than aligning with Alberta's name for just 4 months of the year. Also keep in mind that the BC government's press release is titled "Adopting permanent daylight saving time" and they want it to be called Pacific time.
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-obitua... [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/7913b03ecb5d21754eaa82... [6]: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/7Q52N6O2OJSIESKKW...
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/tz@iana.org/ 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-offici... (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-... 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
Somewhat off-topic, as/and email (in which i am interested) related. Paul Eggert via tz wrote in <ab173302-45bc-4368-affd-c9d2f4341c98@cs.ucla.edu>: |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 ... |[1]: https://datatracker.ietf.org/doc/html/rfc561 |[2]: |https://www.nytimes.com/2016/03/08/technology/raymond-tomlinson-email-ob\ |ituary.html Apologising for trampling on an obituary, but regarding “When it burst onto the scene in 1971,” he added, “it gave the first tangible indication of how far the Internet might go in becoming the ubiquitous anyone-anywhere-to-anyone-anywhere communication system it has become.” i would point to "The Computer as a Communication Device" of Licklider and Tayler, from 1968 (a must-read, and iff only for the drawings; Americas finest, really (honestly)). Maybe even to note "As we may think" from Vannevar Bush, from 1945, though i treat it with suspicion (the elder were so deep we cannot even imagine it, and often so bible-"inspired"). Btw i (who spent a little time) came to { 196 A MAIL BOX PROTOCOL 224 Comments on Mailbox Protocol 354 THE FILE TRANSFER PROTOCOL 385 COMMENTS ON THE FILE TRANSFER PROTOCOL (RFC 354) 458 Mail Retrieval via FTP 475 FTP AND NETWORK MAIL SYSTEM 524 A Proposed Mail Protocol 542 File Transfer Protocol for the ARPA Network 555 Response to Critiques of the Proposed Mail Protocol 561 Standardizing Network Mail Headers 574 Announcement of a Mail Facility at UCSB 577 Mail Priority 640 Revised FTP Reply Codes 644 On the Problem of Signature Authentication for Network Mail 706 On the Junk Mail Problem 751 SURVEY OF FTP MAIL AND MLFL 772 MAIL TRANSFER PROTOCOL 773 COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION STRATEGY rcf821.txt SIMPLE MAIL TRANSFER PROTOCOL (SMTP) john_postel-mail_protocol_via_ftp-1977.txt +722 788 SIMPLE MAIL TRANSFER PROTOCOL } HISTORY OF MAIL and put that in words as follows Electronic mail exchange in general is a concept even older. The earli‐ est well documented electronic mail system was part of the Compatible Time Sharing System (CTSS) at MIT, its MAIL command had been proposed in a staff planning memo at the end of 1964 and was implemented in mid-1965 when Tom Van Vleck and Noel Morris wrote the necessary code. Similar communication programs were built for other timesharing systems. One of the most ambitious and influential was Murray Turoff’s EMISARI. Created in 1971 for the United States Office of Emergency Preparedness, EMISARI combined private electronic messages with a chat system, public postings, voting, and a user directory. During the 1960s it was common to connect a large number of terminals to a single, central computer. Connecting two computers together was rela‐ tively unusual. This began to change with the development of the ARPANET, the ancestor of today’s Internet. In 1971 Ray Tomlinson adapted the SNDMSG program, originally developed for the University of California at Berkeley timesharing system, to give it the ability to transmit a mes‐ sage across the network into the mailbox of a user on a different com‐ puter. For the first time it was necessary to specify the recipient’s computer as well as an account name. Tomlinson decided that the under‐ used commercial at ‘@’ would work to separate the two. Sending a message across the network was originally treated as a special instance of transmitting a file, and so MAIL and MLFL commands were in‐ troduced with RFC 385 as an extension to the file transfer protocol FTP of RFC 354, both in 1972. Until early 1973 many discussions and meetings around FTP occurred, and whereas RFC 475 paved a way towards standardiza‐ tion of mail via FTP, RFC 524 proposed a specialized mail protocol, an opinion that was officially picked up by the FTP RFC 542. Still, for many years, ARPANET mail was sent via FTP. Because it was not always clear when or where a message had come from, RFC 561 in 1973 aimed to formalize electronic mail headers, including “from”, “date”, and “subject”. In 1975 RFC 680 described fields to help with the transmission of messages to multiple users, including “to”, “cc”, and “bcc”. In 1977 these features and others went from best prac‐ tices to a binding standard in RFC 733. In September 1980, with RFC 772, the M(ail) T(ransfer) P(rotocol) was introduced, which had “strong similarities to portions of the File Transfer Protocol”. RFC 821 in Au‐ gust 1982 then introduced the refined S(imple) M(ail) T(ransfer) P(roto‐ col) in use, and usable, almost 42 years later, accompanied by RFC 822 that moved from “ARPA network text” to “internet text message”. Queen Elizabeth II of England became the first head of state to send electronic mail on March 26 1976 while ceremonially opening a building in the British Royal Signals and Radar Establishment (RSRE) in Malvern. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
[I sent this (off-list by accident) earlier. Apologies for any formatting screwups this retransmit might contain.] Date: Tue, 3 Mar 2026 10:51:11 -0800 From: Paul Eggert via tz <tz@iana.org> Message-ID: <6f2df7ee-6e67-4f6f-b0ff-79206d1eb34b@cs.ucla.edu> | No matter what abbreviation we use, there will be trouble. The obvious | abbreviation PT does not conform to the POSIX standard Sorry, but that is utter nonsense. The (current) POSIX standard (the first to admit the existence of tzdb at all, despite it being the dominant timezone database for decades now) provides 3 formats for the TZ environment variable (XBD 8.3), which is the only place any of this is specified at all, as best I can tell: The first, where the first character is ':' and everything else is unspecified. The second, which is in the old SysV type TZ env var format, and where: std and dst Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the Daylight Saving (dst) timezone. where indeed PT would not be usable, but we have no reason to care about that - those who have ancient systems and need to use that format would care, but that is set and used on a system by system basis, and each system owner (each user in fact) can decide for themselves what to use. (PDT, PST, CPT, BCT, ...) And the third, which POSIX calls (informally anyway) "A format specifying a geographical timezone or a special timezone." which allows use of tzdata (or something more or less equivalent, POSIX doesn't specify) which applies when neither of the previous two apply (when the TZ variable neither starts with ':' nor is in the particular format defined for the second variant, which would be the case if, for example, we had "TZ=PT7"). To use that, several requirements are imposed: The data for each geographical timezone shall include: � The offset from Coordinated Universal Time of the timezone's standard time. � If Daylight Saving Time (DST) is, or has historically been, observed: a method to discover the dates and times of transitions to and from DST and the offset from Coordinated Universal Time during periods when DST was, is, or is predicted to be, in effect. � The timezone names for standard time (std) and, if observed, for DST (dst) to be used by tzset( ). These shall each contain no more than {TZNAME_MAX} bytes. Note the final sentence, "These shall each contain no more than {TZNAME_MAX} bytes". No mention of a minimum length at all, they could be 0 bytes if no name for the timezone is appropriate (which it actually could be in much of the world, where all there is is "the time"). The restriction to no less than 3 bytes in the 2nd format is simply to avoid breaking parsers for that string, that have existed with that assumption for years. But as no-one much uses it any more, and certainly no-one we care about -- even the use of a POSIX TZ lookalike string to specify future transitions off into infinity at the end of the known (or anticipated) summer time changes (or lack thereof) is irrelevant to that, that isn't the value of the TZ variable, and isn't (as nor is the rest of what is in a tzdata zone file) specified by POSIX at all - just as long as the data provides the functionality above. XBD 3 (Definitions) doesn't, as best I can tell, say anything at all about timezones or abbreviations for any names thereof. XBD 7.3.5 (locales, and LC_TIME) also says nothing I can see about timezone names, or any length restrictions on any abbreviations that might exist. The spec in XBD14 for <time.h> adds tm_zone, it is a char *, and is a "Timezone abbreviation", and (aside for some specifics about the lifetime of its value) that's all that is said about it. It could be anything, no length restrictions at all, no syntax requirements either. Similarly, the specs in XSH 3 for localtime and asctime (and ctime which is just asctime plus a bit) say nothing about the tm_zone field (asctime nothing at all, it isn't used there) - localtime just says of tm_zone: If the tm structure member tm_zone is accessed after the value of TZ is subsequently modified, the behaviour is undefined. That's it. The tm struct is required to have the relationship with the input time_t as defined in XBD 4.19 - which says nothing at all about what tm_zone should be set to. The spec for gmtime() says nothing about the tm_zone field, however for gmtime_r(): Upon successful completion, gmtime_r( ) shall return the address of the structure pointed to by the argument result. The structure's tm_zone member shall be set to a pointer to the string "UTC", which shall have static storage duration. which is the most specific definition of tm_zone's value I can find anywhere, but is certainly not relevant here. The mktime() function takes a struct tm, but doesn't use the tm_zone field at all, except to (eventually, in the case of a successful conversion) set it (and all the rest of the members of the struct tm) to what localtime() would return given the result returned from mktime(). The strftime() format %Z accesses the tm_zone field Z Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists. [tm_isdst, tm_zone ] That says nothing about any length requirement, and even explicitly allows for the zone name to be absent (no bytes). The strptime() function %Z conversion is specified as: Z The timezone name. If this name matches the name pointed to by tzname[1], and the names pointed to by tzname[0] and tzname[1] differ, then the tm_isdst member of the tm structure pointed to by tm shall be set to 1. Otherwise, if this name matches the name pointed to by tzname[0] then the tm_isdst member of the tm structure pointed to by tm shall be set to 0. The tm_zone and tm_gmtoff members of the structure may also be set in an unspecified manner. Members other than tm_isdst, tm_zone, and tm_gmtoff may be affected if an s conversion is also performed but shall otherwise not be affected. Nothing at all about length requirements, nor syntax for that matter, all that is more about setting tm_isdst than tm_zone. The date command just specifies use of the strftime() conversions, such that the default format is: date "+%a %b %e %H:%M:%S %Z %Y" where the tm_zone field is entirely governed by what strftime() specifies for %Z (which as seen above, is more or less "anything goes"). The only wording which can even half be interpreted to imply what you're suggesting, is in the XSH 3 page for tzset(): The tzset( ) function shall set the external variable tzname as follows: tzname[0] = "std"; tzname[1] = "dst"; where std and dst are as described in XBD Chapter 8 (on page 167). except that XBD 8 doesn't define std or dst at all for the first of the three formats, it does require at least 3 chars (and no more than, and all alphanumeric or + or -) when the 2nd format for TZ is used, and basically nothing at all (just the max length) when the 3rd variant (the one we all use) is used. It all doesn't matter much, the idea that a timezone has a constant offset from UTC (for the "timezone" variable) and either one or two names (no more) for timezone name abbreviations is all obsolete garbage, and ought to be completely forgotten. But if you feel that the above requires tzname[0] to be set to a 3 letter abbrev, by all means set it to one, but nothing says that tm_zone has to be set to the same string. Please stop spreading nonsense about what POSIX requires. There might be people who believe what you say. If you believe I'm wrong about this, then please cite the text from the standard which supports your view. | or to TZDB guidelines, If those actually require 3 (or more) chars (letters perhaps, but then +07 wouldn't work) then change the quidelines. It is that simple. There is no reason for such a restriction - and what's more, we should be able to create zones which reflect the "military" zone names (A B C ... Z, missing just I I think it is, but it has been a while) which are all 1 char long (but are unable to represent offsets that aren't an even number of hours). | I installed into the development repository the proposed | patch, which uses a "-07" placeholder that also should work but is | jarring in a North American context. It is jarring in all contexts, and I fail to see any reason why North America should be given any kind of special treatment in this international issue. Of course, the ideal would either be to do away with timezone abbreviations entirely ("-07" is can be trivially derived from tm_gmtoff should anyone really desire to output something like that), or go back to supplying rational abbreviations for all zones (regardless of whether they have any "offical" status or not). Removing the abbreviations would also avoid all the issues related to the lifetime of the tm_zone field (it would simply be NULL, always). kre
On 2026-03-06 18:08, Robert Elz via tz wrote:
std and dst Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the Daylight Saving (dst) timezone.
where indeed PT would not be usable, but we have no reason to care about that
Unfortunately we do. See Internet RFC 9636 section 3.3 <https://www.rfc-editor.org/rfc/rfc9636#name-tzif-footer>. It says the TZ strings embedded in TZif files need to conform in this respect to POSIX.1-2017, which has that three-byte minimum. Moreover, RFC 9636 section 4 <https://www.rfc-editor.org/rfc/rfc9636#name-interoperability-considerat> says "Time zone designations MUST consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, '-', and '+'." These restrictions also derive from POSIX. Although we could relax these restrictions in later RFCs, that's not something we could reasonably expect all downstream TZif readers and producers to implement by November, so for now the restrictions do impinge on what we can put into America/Vancouver for this issue. Besides, alphabetic time zone abbreviations are problematic given their ambiguity and lack of standardization, and so I doubt whether it'd be wise to relax the restrictions and encourage use of shorter abbreviations like "PT" or (shudder!) "O". We have trouble enough as it is with these things.
the idea that a timezone has a constant offset from UTC (for the "timezone" variable) and either one or two names (no more) for timezone name abbreviations is all obsolete garbage,
I quite agree, and POSIX.1-2024 started the ball rolling on getting rid of that garbage. Alas the job is still incomplete. (This is veering off into a different subject of course.)
Date: Fri, 6 Mar 2026 20:39:23 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <0ae0a22c-cc42-4671-bb3c-fdc4c7ec3237@cs.ucla.edu> | Although we could relax these restrictions in later RFCs, that's not | something we could reasonably expect all downstream TZif readers and | producers to implement by November, so for now the restrictions do | impinge on what we can put into America/Vancouver for this issue. First, almost none of that is POSIX as previously claimed, the section 3.3 restriction almost might be, but that's easy to avoid by simply not putting the string into the zone file, if it would violate that spec. That's unlikely to even be noticed, as for most practical purposes it isn't used (few applications want to translate dates very far into the future, as everything there is speculation anyway, so just throw in an extra hundred years of transitions, using whatever the rule would be, instead). If there is an application that breaks (or objects) based upon the section 4 restriction, it ought to simply be dumped (that is, if there are really many applications that read TZif files, aside from tzcode - most others seem to want to parse the input files, which to me is weird, but helpful here, as those files aren't standardised by anyone). I understand maximum sizes can't easily be violated, but anything insisting upon minimum sizes without a very good reason is just being petty. Again, the only place that POSIX ever mandated >=3 char abbreviations is (almost was now) in the specification of the TZ environment variable, and just possibly in that spec for what to set tzname[] values to, none of which isn't being used by TZDATA (the embedded strings not withstanding, those aren't TZ variable assignments, just strings using a similar syntax - POSIX doesn't apply and never did, you could have made them be anything). | Besides, alphabetic time zone abbreviations are problematic given their | ambiguity and lack of standardization, I agree with the premise, those things are useful only for display to humans who understand the meanings of the strings given for zones for whick they are familiar. For anything else they are useless. But I disagree with the conclusion: | and so I doubt whether it'd be | wise to relax the restrictions and encourage use of shorter | abbreviations like "PT" or (shudder!) "O". Doing more of that would be a good thing - the more it is made clear to everyone just how useless those things are in general, the better. No sane program should ever be parsing them, unless some specification gives them some particular meaning in that spec's particular context, as for example the e-mail standards do for a limited set of them. Trying to keep making them useful or less ambiguous, or whatever, is entirely the wrong direction to be headed. | We have trouble enough as it is with these things. No, we have trouble, we need to make even more of it, until people learn just what they are good for (not much), and what they aren't. Continuing to bow to the idiots, just encourages more idiots to appear. | I quite agree, and POSIX.1-2024 started the ball rolling on getting rid | of that garbage. Alas the job is still incomplete. (This is veering off | into a different subject of course.) It is indeed. kre ps: I eventually checked, for anyone who cares, it is J that is unused, not I, in the 1 letter (military) identifier space. Using "O" for summer time in much of Western Europe would seem just fine to me.
On Mar 7, 2026, at 9:43 AM, Paul Eggert via tz <tz@iana.org> wrote:
There are many, including the app I'm writing this email with. I daresay more apps read TZif via other means than via tzcode and derivatives.
Any idea: 1) how many of them do so because they're using some standard library (e.g., ICU) that doesn't sit atop a tzcode-based C standard library vs. other reasons, such as an application having its own code? 2) how many of them do so because the tzcode doesn't provide some capability (e.g., calls to get a list of transitions or to determine when the next transition will be) vs. some other reason?
On 2026-03-07 09:54, Guy Harris wrote:
On Mar 7, 2026, at 9:43 AM, Paul Eggert via tz <tz@iana.org> wrote:
I daresay more apps read TZif via other means than via tzcode and derivatives.
Any idea:
1) how many of them do so because they're using some standard library (e.g., ICU) that doesn't sit atop a tzcode-based C standard library vs. other reasons, such as an application having its own code?
Although I haven't done a survey, I expect it's usually using a library, such as one of those mentioned in <https://data.iana.org/time-zones/tz-link.html#TZif> (by no means a complete list).
2) how many of them do so because the tzcode doesn't provide some capability (e.g., calls to get a list of transitions or to determine when the next transition will be) vs. some other reason?
I expect this is rarer. However, one major API does that sort of thing: the time zone API of C++20 and later <https://en.cppreference.com/w/cpp/chrono.html#Time_zone>. I don't track its implementations. Whatever they are, they can't be based just on tzcode as the tzcode API doesn't support that sort of thing.
Paul Eggert via tz wrote in <bc9b52dd-5394-4575-9498-69160ee06eb3@cs.ucla.edu>: |On 2026-03-07 01:38, Robert Elz wrote: |> if there are really |> many applications that read TZif files, aside from tzcode | |There are many, including the app I'm writing this email with. I daresay |more apps read TZif via other means than via tzcode and derivatives. It seems to me it uses ICU, and ICU says // Check for TZ_ICU_MAGIC signature at file start. If we get a // signature mismatch, it means we're trying to read a file which // isn't a ICU-modified-zic-created zoneinfo file. Typically this // means the user is passing in a "normal" zoneinfo directory, or // a zoneinfo directory that is polluted with other files, or that // the user passed in the wrong directory. See how https://github.com/unicode-org/icu/blob/main/icu4c/source/tools/tzcode/tz2ic... (cannot be read from Iran or North Korea or even Cuba i think, but that shame aside) "builds transition tables" like grazy. See comments like "why??". They do perform value checks (i was only shortly glancing over). I could imagine they would run to a carefully designed new schematized variant rather sooner than later. (Especially if there would be an easy scheme tester, say libucl of Vsevolod Stakhov, both "well-known to famous": https://github.com/vstakhov/libucl Just my one cent. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 2026-03-07 15:25, Steffen Nurpmeso via tz wrote:
It seems to me it uses ICU
On my Ubuntu 25.10 platform, my email client (Thunderbird) uses the GNU C library to read TZif data. I was talking about that usage, not any ICU usage. On my platform ICU has its own copy of the time zone data, and this copy can be out of sync with tzdata's copy on the same platform. Although failures due to mismatch are rare, they can be a mess when they do happen, and that has partly inspired the current thread. For more, see the following (tz-link.html refers to this page): https://unicode-org.github.io/icu/userguide/datetime/timezone/#updating-the-... PS. Ubuntu makes matters even more complicated by using snaps, each of which can have their own private copy of both tzdata and CLDR, and all these copies can be out of date and/or mismatch each other! But that's Ubuntu's problem, not TZDB's or CLDR's.
On Mar 7, 2026, at 4:17 PM, Paul Eggert via tz <tz@iana.org> wrote:
On my Ubuntu 25.10 platform, my email client (Thunderbird) uses the GNU C library to read TZif data. I was talking about that usage, not any ICU usage.
...or any usage by anything else not using the C API. So that's a case of an independent reimplementation of the same C/POSIX API that the tzcode implements. And it's not "my email client", it's "any code on my machine that uses that C/POSIX API", probably including, for example, "ls". That (re)implementation is intended to be compatible with other implementations; it probably exists because of a combination of licensing reasons and perhaps "not wanting ties to tzcode release schedules" reasons, and it's somewhat subject to the same constraints as the tzcode implementation, although the GNU folks are known to discard some POSIX constraints without a thought other than "don't like it, set POSIXLY_CORRECT in the environment" (e.g., getopt() behaves, by default, in some user-visibly non-POSIX-compliant ways).
Guy Harris via tz <tz@iana.org> writes:
Paul Eggert via tz <tz@iana.org> writes:
On my Ubuntu 25.10 platform, my email client (Thunderbird) uses the GNU C library to read TZif data. I was talking about that usage, not any ICU usage. So that's a case of an independent reimplementation of the same C/POSIX API that the tzcode implements. [...]
Yes, an independent reimplementation maintained by [checks notes] some guy named Paul Eggert. I bet he sucks. DES -- Dag-Erling Smørgrav - des@des.no
On Mar 8, 2026, at 4:41 AM, Dag-Erling Smørgrav <des@des.no> wrote:
Guy Harris via tz <tz@iana.org> writes:
Paul Eggert via tz <tz@iana.org> writes:
On my Ubuntu 25.10 platform, my email client (Thunderbird) uses the GNU C library to read TZif data. I was talking about that usage, not any ICU usage. So that's a case of an independent reimplementation of the same C/POSIX API that the tzcode implements. [...]
Yes, an independent reimplementation maintained by [checks notes] some guy named Paul Eggert. I bet he sucks.
And not as independent as I'd originally thrught: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/3TRCQROTP2WT4OKEWC... "The GNU C Library (see prep.ai.mit.edu:pub/gnu/glibc-1.05.tar.z) is derived from Olson's 1989 code. Here are its changes:..." and there was, perhaps, *another* Olson-derived implementation originally used on Linux: "Linux's code for timezones (see tsx-11.mit.edu:pub/linux/sources/sbin/timesrc.tar.Z) is also derived from Olson's 1989 code, but it has only the following minor changes: ..." The GNU libc code was, as I remember, originally done by Roland McGrath. Looking at the current tip-of-main-branch code from GNU libc (which is what I think many Linux distributions use), it looks different - and not just in coding style - from the current tzcode version. I don't know who's responsible for those changes. The musl C library, used by some *other* Linux distributions, has its own separate implementation. And then there's the code used by at least a plurality of smartphones on the planet, from the Bionic C library, which looks more directly tzcode-derived. I don't know what code Huawei's doing in its collection of various operating systems all of which, at least from the collection of Wikipedia pages about those various operating systems, seem to be based on each other in some cyclic graph, uses, so I can't speak for their smartphones. But most of those have, as I noted, constraints stemming from a desire to Look Somewhat Like C and Unix. Various *other* programming languages have their own libraries. I don't have a list of which ones are wrappers around the C/POSIX APIs and which are completely independent. Some of the latter, as noted, don't read TZif files.
On 2026-03-08 09:45, Guy Harris via tz wrote:
Looking at the current tip-of-main-branch code from GNU libc (which is what I think many Linux distributions use), it looks different - and not just in coding style - from the current tzcode version. I don't know who's responsible for those changes.
Partly I am. For example, I rewrote GNU mktime in 1995. Given all the other rewriting, at this point it'd be a stretch to say there's much in common between tzcode and glibc-like libraries. That's not the case for FreeBSD and NetBSD - their libraries could sync with tzcode with just a little bit of engineering. tzcode zic and zdump are a different matter: as far as I know they're used pretty much unchanged among all systems that use C code to generate and dump TZif files. tzcode 'date' is in yet another category: it was derived from old BSD date and as far as I know nobody uses it downstream.
Guy Harris via tz wrote in <33322694-56FD-4D92-9365-4B85EA629012@sonic.net>: |On Mar 8, 2026, at 4:41 AM, Dag-Erling Smørgrav <des@des.no> wrote: |> Guy Harris via tz <tz@iana.org> writes: |>> Paul Eggert via tz <tz@iana.org> writes: |>>> On my Ubuntu 25.10 platform, my email client (Thunderbird) uses the |>>> GNU C library to read TZif data. I was talking about that usage, not |>>> any ICU usage. |>> So that's a case of an independent reimplementation of the same |>> C/POSIX API that the tzcode implements. [...] |> |> Yes, an independent reimplementation maintained by [checks notes] some |> guy named Paul Eggert. I bet he sucks. | |And not as independent as I'd originally thrught: | | https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/3TRCQROTP2WT4O\ | KEWC6UKAQ34WOJT5OH/ | |"The GNU C Library (see prep.ai.mit.edu:pub/gnu/glibc-1.05.tar.z) is \ |derived from Olson's 1989 code. Here are its changes:..." ... |The musl C library, used by some *other* Linux distributions, has its \ |own separate implementation. But to note it started over half a decade before the RFC on some binary file format. |And then there's the code used by at least a plurality of smartphones \ |on the planet, from the Bionic C library, which looks more directly \ |tzcode-derived. | |I don't know what code Huawei's doing in its collection of various \ |operating systems all of which, at least from the collection of Wikipedia \ |pages about those various operating systems, seem to be based on each \ |other in some cyclic graph, uses, so I can't speak for their smartphones. | |But most of those have, as I noted, constraints stemming from a desire \ |to Look Somewhat Like C and Unix. | |Various *other* programming languages have their own libraries. I don't \ |have a list of which ones are wrappers around the C/POSIX APIs and \ |which are completely independent. Some of the latter, as noted, don't \ |read TZif files. RFC 8536 came in 2019. 9636 in 2024. There are changes to 8536. There is a new format. There are bugs. There are what i would interpret as "wild" in-code comments. For some practice, see for example [585a0a78f9] of musl's src/time/__tz.c: explicitly prefer 64-bit/v2 zoneinfo tables since commit 38143339646a4ccce8afe298c34467767c899f51, the condition sizeof(time_t) > 4 is always true, so there is no functional change being made here. but semantically, the 64-bit tables should always be preferred now, because upstream zic (zoneinfo compiler) has quietly switched to emitting empty 32-bit tables by default, and the resulting backwards-incompatible zoneinfo files will be encountered in the wild. Oops. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 2026-03-09 08:21, Steffen Nurpmeso via tz wrote:
Guy Harris via tz wrote in <33322694-56FD-4D92-9365-4B85EA629012@sonic.net>: |On Mar 8, 2026, at 4:41 AM, Dag-Erling Smørgrav <des@des.no> wrote: |> Guy Harris via tz <tz@iana.org> writes: |>> Paul Eggert via tz <tz@iana.org> writes: |>>> On my Ubuntu 25.10 platform, my email client (Thunderbird) uses the |>>> GNU C library to read TZif data. I was talking about that usage, not |>>> any ICU usage. |>> So that's a case of an independent reimplementation of the same |>> C/POSIX API that the tzcode implements. [...] |> |> Yes, an independent reimplementation maintained by [checks notes] some |> guy named Paul Eggert. I bet he sucks. | |And not as independent as I'd originally thrught: | | https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/3TRCQROTP2WT4O\ | KEWC6UKAQ34WOJT5OH/ | |"The GNU C Library (see prep.ai.mit.edu:pub/gnu/glibc-1.05.tar.z) is \ |derived from Olson's 1989 code. Here are its changes:..." ... |The musl C library, used by some *other* Linux distributions, has its \ |own separate implementation.
But to note it started over half a decade before the RFC on some binary file format.
|And then there's the code used by at least a plurality of smartphones \ |on the planet, from the Bionic C library, which looks more directly \ |tzcode-derived. | |I don't know what code Huawei's doing in its collection of various \ |operating systems all of which, at least from the collection of Wikipedia \ |pages about those various operating systems, seem to be based on each \ |other in some cyclic graph, uses, so I can't speak for their smartphones. | |But most of those have, as I noted, constraints stemming from a desire \ |to Look Somewhat Like C and Unix. | |Various *other* programming languages have their own libraries. I don't \ |have a list of which ones are wrappers around the C/POSIX APIs and \ |which are completely independent. Some of the latter, as noted, don't \ |read TZif files.
RFC 8536 came in 2019. 9636 in 2024. There are changes to 8536. There is a new format. There are bugs. There are what i would interpret as "wild" in-code comments. For some practice, see for example [585a0a78f9] of musl's src/time/__tz.c:
explicitly prefer 64-bit/v2 zoneinfo tables
since commit 38143339646a4ccce8afe298c34467767c899f51, the condition sizeof(time_t) > 4 is always true, so there is no functional change being made here. but semantically, the 64-bit tables should always be preferred now, because upstream zic (zoneinfo compiler) has quietly switched to emitting empty 32-bit tables by default, and the resulting backwards-incompatible zoneinfo files will be encountered in the wild.
Most distros try hard to maintain backward compatibility of data and files, so users don't have to figure out some new time zone id setting, although mobiles may have other goals. Most libraries incorporate code changes for reliability on their own release schedules, often derived from BSD releases which stay pretty close to the reference implementation, although they may use their own lower level time functions. -- 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
Paul Eggert via tz wrote in <0ae0a22c-cc42-4671-bb3c-fdc4c7ec3237@cs.ucla.edu>: |On 2026-03-06 18:08, Robert Elz via tz wrote: ... |> where indeed PT would not be usable, but we have no reason to care about |> that | |Unfortunately we do. See Internet RFC 9636 section 3.3 One more of those RFCs that should never have been written! And if standardizing a binary file format of some library, then some standardized binary format should have been used. I was asking for CBOR by then, granted for the over-the-net tz stuff that does not fly, and, of course, only as a suggestion, yaml or even (i hate it for several mostly good Unicode reasons) json or anything that is standardized and has schema support. Ie, all the same data, all the same format. The "Interoperability Considerations" is self-speaking against the binary "upward-compatible" of the introduction, and mostly everywhere the project code is used, accompanying the data, as i see it, otherwise the considerations have to be considered. Right. Btw personally i am hoping that the Go TZif reader that you link from your own homepage, that its comments form the critique i would state, especially that ~"and now we can form the actual data" is indeed Monty Pythonesque. And then you even need bug workarounds for certain implementations. I would vote for adding another variant, in a standardized container format, eventually growing out the old one, installed like /etc/localtime.X where X is accordingly. The RFC speaks about "obsolescent version-1-only readers MUST", so the RFC implies code changes are doable on even those obsolescent version-1-only readers. (Shudder.) ... |Although we could relax these restrictions in later RFCs, that's not ... Or drop those altogether. They have no value, and never had, really, in my opinion, except for possibly specifying a data schemata. Soon all readers are obsolescent, and the new RFC would have to add more paragraphs on "placeholder version XY datablocks". There is still over a decade until 64-bit time is really needed. Turn to localtime.X where X is, i am guessing, JSON. (Despair here.) (Btw, and now off-topic, i know a former member of FSF Europe who is prowd of a personal signature of Mr. Stallman, and who is in the process of developing KEKS is compact, deterministic, concise and streaming binary serialisation format. It is aimed to be lightweight in terms of CPU, memory, storage and codec implementation size usage. It supports wide range of data types, making it able to transparently replace JSON. KEKS/Schema is a schema definition format for describing data structures validation steps. etc with already implementations in C, Go, python3, tcl, if i get this right. git://git.cypherpunks.su/keks.git. Since you seem to be interested in good small things, and surrounding the FSF universe, like Diaz's lzip.) ... |something we could reasonably expect all downstream TZif readers and |producers to implement by November, so for now the restrictions do |impinge on what we can put into America/Vancouver for this issue. | |Besides, alphabetic time zone abbreviations are problematic given their |ambiguity and lack of standardization, and so I doubt whether it'd be |wise to relax the restrictions and encourage use of shorter |abbreviations like "PT" or (shudder!) "O". We have trouble enough as it |is with these things. | |I quite agree, and POSIX.1-2024 started the ball rolling on getting rid |of that garbage. Alas the job is still incomplete. (This is veering off |into a different subject of course.) Drop it altogether. There are incompatibilities, there are bugs, the number of actively developed TZif readers is not that large, as far as i know, and those which do often use languages which ship infrastructure to go JSON/X out-of-the-box, and easily. And with automatic schema you then also get *data content verification* for free, as opposed to only binary data structure. (As in, "how many readers perform really proper verification?") And with a filename with regular file extension you integrate in "the normal" mime.types approach much better, ie, RFC 9636's "When a TZif file is used in a MIME message entity, it SHOULD be indicated by one of the following media types" requires "magic" logic (aka file content inspection, as opposed to only file extension checks via eg /etc/mime.types) that many applications do not support, not even those that make use of the monstrous (imho) freedesktop.org/xdg/shared-mime-info it seems $ pkginfo -l shared-mime-info | grep -i tz usr/share/mime/application/x-tzo.xml and that one unfortunately cannot get rid of $ prt-get dependent shared-mime-info gobject-introspection $ prt-get dependent gobject-introspection glib-introspection $ prt-get dependent glib-introspection gdk-pixbuf at-spi2-core harfbuzz Sigh. Granted file(1) of NetBSD's Zoulas can $ file /usr/share/zoneinfo/Iran /usr/share/zoneinfo/Iran: timezone data (slim), version 2, no gmt time flags, no std time flags, no leap seconds, 71 transition times, 6 local time types, 28 abbreviation chars pretty impressive, but wait $ file --mime-type /usr/share/zoneinfo/Iran /usr/share/zoneinfo/Iran: application/octet-stream or what $ file --mime-encoding /usr/share/zoneinfo/Iran /usr/share/zoneinfo/Iran: binary Noone ever cared. (But even if, i for example have my own mime.types ie based on extensions, and it will prowdly support things like # built-in mimetype application/x-lzma lzma # built-in (not for sending mail) mimetype ?only-handler application/x-tar-lzma tar.lzma with the next release.) "Get rid of that garbage", yes. (RFC, not readers -- i have not really looked at their code. But code there is, sometimes quite a bit.) And tzdata.si is great. Thank you. --End of <0ae0a22c-cc42-4671-bb3c-fdc4c7ec3237@cs.ucla.edu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 2026-03-06 19:08, Robert Elz via tz wrote:
If those actually require 3 (or more) chars (letters perhaps, but then +07 wouldn't work) then change the quidelines. It is that simple. There is no reason for such a restriction - and what's more, we should be able to create zones which reflect the "military" zone names (A B C ... Z, missing just I I think it is, but it has been a while) which are all 1 char long (but are unable to represent offsets that aren't an even number of hours).
See attached: Juliet is localtime; Zulu is GMT; Alpha..Mike are GMT+1..12; November..Yankee are GMT-1..12. I used to add them under .../ITU, but now under .../Etc, including spelling variations Alfa, Juliett, Whiskey (I'm Scottish/Irish), X-ray, and single letters. -- 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
participants (15)
-
Arthur Olson -
Brian Inglis -
Chris Walton -
Dag-Erling Smørgrav -
Davis Carlson -
daviscarlson00@gmail.com -
Guy Harris -
Matthias Urlichs -
Michael Bain -
Paul Eggert -
Philip Paeps -
Robert Elz -
robertbastian@unicode.org -
Steffen Nurpmeso -
Tim Parenti