On Mar 16, 2022, at 11:16, Tim Parenti via tz <tz@iana.org> wrote:This is what happened in America/New_York in 1942, except the abbreviations were EWT and EPT, right?
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked.
With that in mind, I’m thinking that the best approach might be (to take a page from the Hippocratic Oath) to “do no harm”. Given that the overall thrust of the Bill is ‘permanent DST’, perhaps we should reflect just that —i.e. the “permanent” abbreviations would become EDT | CDT | MDT | PDT, the 'tm_isdst' member of the 'tm' struct would always return a positive value, etc.
Doing this would narrowly confine the scope of the changes to DST transition handling itself; without the need to go change the meanings of abbreviations as defined in the relevant RFCs and other standards with the concomitant needed changes in downstream applications.
Cheers!
|---------------------------------------------------------------------|| Frederick F. Gleason, Jr. | Chief Developer || | Paravel Systems ||---------------------------------------------------------------------|| A room without books is like a body without a soul. || || -- Cicero ||---------------------------------------------------------------------|