[tz] Permanent DST in the United States

[Matt Johnson-Pint]

Here's a link to a video of Rubio's comments on the Senate floor for this
bill:
https://www.youtube.com/watch?v=_WS64Q3-emk

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: <https://mm.icann.org/pipermail/tz/attachments/20220315/6b374985/attachment.html>