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.

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 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

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

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.

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 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

[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

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?

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 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).

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.

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)

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)