On 10/2/2026 6:04 PM, Doug Ewell via tz wrote:
I think the principle in avoiding “xDT” (for any ‘x’) to refer to a time zone observed 12 months a year is that “daylight saving time” is conceptually a deviation from “standard time.” Even if that deviation is observed twice as long as standard time, it is still a deviation.
At some point the deviation becomes the standard ... the people of Ireland have it right. IST most of the year and GMT during the deviated winter time.
Europe as a group has the naming pattern of inserting a character instead of changing a character. WET, CET and EET become WEST, CEST and EEST during "summer" time. The UK changes from GMT to BST (British Summer Time).
I can understand the reluctance to use "xDT" for a permanent time zone since the "xDx" label has historically been applied to "daylight time".
Now that we are within a month of the traditional end of DST and Microsoft and Google (and others) have updated for the western Canada changes we should start seeing antidotal references to time, such as scheduling meetings between people in Seattle and Vancouver or Denver and Calgary. When one sets a meeting for 9am on November 2nd "Pacific Time" or 10am "Mountain Time" what time does it show up? If everything is working within the downstream software the meeting originator should see the times noted and the participants should see the correct local time.
The conversation over the telephone or email before setting up the meeting could vary. If I say I'll send a meeting invite for 9am Pacific Time from Seattle the recipient in Vancouver may be surprised when it appears as a 10am meeting. ("You said 9am on your call/in your email!") Which leads to the human changes which cannot be made by tzdata or any downstream software (unless the scheduling software is aware the invitees are in a different time zone and alerts the scheduler).
I doubt the Vancouver participant will say "I am in PCT". They may say they are on Vancouver time or Pacific Time (which is ambiguous to a person who knows Seattle as Pacific Time). If the trend becomes "Pacific Daylight Time" there will be an argument for using PDT as the abbreviation despite the historical usage. But it is too soon to make that argument without end user data that is less theoretical than predictions.
I agree with the maintainers that a decision to change america/vancouver to PCT or make other vanity changes need not be rushed. The most important part of tzdata is the offsets and those are correct as of 2026e. Most downstream software is handling the labels.
