February 2025 - tz - lists.iana.org

Chile's Aysén Region polled about switching from -04/-03 to -03 all year
by Paul Eggert March 20, 2025

March 20, 2025

Beginning this week and continuing through the end of the month, the citizens of Chile's Aysén Region are being polled virtually for a non-binding resolution[1] to switch from the their current timekeeping regime TZ="America/Santiago" (-04 in winter, -03 in summer) to permanent -03 (like TZ="America/Punta_Arenas"). If this happens, we'll need to create a new Zone America/Coyhaique to record the change, which would likely have practical effect on 2025-04-05 at the earliest. Unfortunately, the SurveyMonkey form used for the poll requires no authentication, which raised plausible worries this week about ballot-stuffing[2]. [1]: https://www.diarioregionalaysen.cl/noticia/actualidad/2024/11/lanzan-consul… [2]: https://www.diarioregionalaysen.cl/noticia/actualidad/2024/11/encuesta-sobr…

3 4

North Dakota HB 1259 requiring year-round standard time
by asinglet＠epic.com March 1, 2025

March 1, 2025

https://legiscan.com/ND/text/HB1259/2025 HB 1259 passed the North Dakota House last week. No idea on whether it will pass the ND Senate or be signed into law. The tricky thing about this bill is that it does not have an implementation time frame. Theoretically if it moves through in the next week or two, we could be looking at a repeat of the Lebanon 2023 fiasco. I hope if they are going to pass it, they take their time.

4 4

Maryland HB1290
by Arthur Olson Feb. 21, 2025

Feb. 21, 2025

The hearing on Maryland House Bill 1290, "Full-Year Daylight Saving Time," has been cancelled: https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb1290 In past years such bills died in committee, but only having had a hearing; this is the earliest death yet for such a bill. Perhaps the state legislators have more important matters on their minds this year. @dashdashado

2 1

EST5EDT should not resolve to America/New_York because they have different offsets
by Austin Hill Feb. 21, 2025

Feb. 21, 2025

Hello - I recently filed a GitHub issue against the perl DateTime::TimeZone library, which uses your database: https://github.com/houseabsolute/DateTime-TimeZone/issues/58#issue-28644459… I noticed that EST5EDT now resolves to America/New_York. This is problematic because the two do not have the same offset - EST5EDT is -5:00 and America/New_York is -04:56:02. My ticket was closed because the behavior appears to be caused by changes in your database in commit a0b09c0 ( https://github.com/eggert/tz/commit/a0b09c0230089252acf2eb0f1ba922e99f7f4a03 ). Is this something that you would consider changing? Thanks! - Austin Hill

9 16

localized date without time
by Alejandro Colomar Feb. 12, 2025

Feb. 12, 2025

Hi Paul, Link: <https://github.com/shadow-maint/shadow/issues/1057> Currently, shadow utils' passwd(1) (and several other programs) uses UTC time when printing. That is: $ passwd -S alx alx P 2023-09-20 0 99999 7 -1 the date from above is a UTC representation of $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 However, shadow utils programs, such as chage(1), use local time in input. That timestamp was set by chage(1), interpreting a local date: $ sudo chage -d 2023-09-21 alx $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 $ date Wed Jul 31 07:54:17 CEST 2024 This is rather confusing, and we think that passwd(1) should also print the date in local time, when printing human-readable dates. However, I think it might be better to show the timezone information together with the date, to be clear that what we're printing is local time. Do you think that's reasonable? Or maybe it's understood that when printing a date some timezone information is implicitly local? I didn't find any way to print timezone information in ISO 8601, if you don't print the time together with the date. That is, ISO 8601 says: C.1.3.1 Date A date string represents one of the following: • year, month, and day (e.g. 2001-02-03) • year and month (e.g. 2008-12 ) • year (e.g. 2008) and C.1.3.2 Date and Time A date/time string is composed according to one of three representations as illustrated in the following three examples: • 2001-02-03T09:30:01 • 2004-01-01T10:10:10Z • 2004-01-01T10:10:10+05:00 but I don't see any way to print something like 2023-09-21+02:00 in standardese. Is this a defect in ISO 8691? I see that in C.1.3.2, it says "Zone-offset may be omitted or included", so I guess we can just omit it. What do you think we should do? Thanks! And have a lovely day! Alex -- <https://www.alejandro-colomar.es/>

5 13