[tz] Permanent DST in the United States
jacob at jhpratt.dev
Tue Mar 15 20:05:12 UTC 2022
Good point with regard to the abbreviation. I know some RFCs explicitly
assume "PST" is UTC-8. These RFCs, though deprecated, are still required to
be followed in new code (I did this not too long ago).
With regard to the delayed implementation, it sounds like there was an
amendment included. The Congressional website doesn't yet reflect this, but
in my experience it takes a day or two for the website to be updated
(including for the vote itself).
Rubio said, however, that an amendment to the bill would delay its
> implementation until November 2023 in order to give the airline and travel
> industries, which operate on strict timetables, sufficient leeway to
> prepare for the change.
On Tue, Mar 15, 2022 at 4:01 PM Paul Eggert <eggert at cs.ucla.edu> wrote:
> On 3/15/22 12:05, Jacob Pratt via tz wrote:
> > there is no clause that delays implementation, so it looks like it would
> > take effect immediately. This could be problematic if the bill becomes
> > near or after the November clock change.
> It would be problematic even if it becomes law this month, as it would
> effectively change time zone names and abbreviations immediately. For
> example, the time zone abbreviation in Los Angeles would immediately
> change from "PDT" to "PST" (though the UTC offset would not change).
> A *lot* of computer software assumes that timezone abbreviations like
> "PST" have their longstanding meanings. This software was obviously
> misguided, but it's out there and changing it will be quite a hassle. I
> don't envy people who will have the responsibility for cleaning up the
> resulting mess where "PST" has one meaning for older timestamps and a
> different meaning for newer ones and existing standards like Internet
> RFC 5322 continue to say things like "PST is semantically equivalent to
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz