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

Amendment reference: https://news.yahoo.com/senate-unexpectedly-approves-legislation-abolish-190710035.html

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.

Jacob Pratt

On Tue, Mar 15, 2022 at 4:01 PM Paul Eggert <eggert@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 law
> 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
-0800".