[tz] Permanent DST in the United States

Matt Johnson-Pint mattjohnsonpint at gmail.com
Tue Mar 15 22:27:56 UTC 2022

Here's a link to a video of Rubio's comments on the Senate floor for this

At 3:56, he discusses the delay to November 2023.

Looking forward to seeing that added to the official bill.

On Tue, Mar 15, 2022 at 1:05 PM Jacob Pratt via tz <tz at iana.org> wrote:

> 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 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
>> 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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20220315/6b374985/attachment.htm>

More information about the tz mailing list