- tz - lists.iana.org

DST offsets other than +1
by Doug Ewell March 4, 2025

March 4, 2025

1. Are there any time zones that currently observe DST with an offset other than adding one hour? (For this question, I am treating “negative DST” zones like Europe/Dublin and Africa/Windhoek as if they observed “standard” time in winter and adjusted time in summer. Also, for this question I am only interested in current practice, not historical.) 2. Is there an easy way I could have looked up this information in the tz files? (“Easy” means without exhaustively parsing all the Rule and Zone lines, as a processor would have to do.) Thanks, -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

6 8

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 17

ELIZA Reanimated
by Brooks Harris Jan. 23, 2025

Jan. 23, 2025

ELIZA Reanimated: The world’s first chatbot restored on the world’s first time sharing system https://arxiv.org/pdf/2501.06707 Has anyone asked ELIZA what time it is?

3 3

Re: Notice of a problem with the Asia/Tokyo time zone
by Paul Eggert Jan. 22, 2025

Jan. 22, 2025

> From: Patrick BENNY <patrick.benny(a)mixi.co.jp> > Date: Mon, Jan 20, 2025 at 6:41 PM > The Asia/Tokyo time zone seems to have been linked with Australia, probably > by mistake. > Please see this related difference from the zone1970.tab file, observed > when comparing 2024b and 2025a. > > 186c186 > < JP +353916+1394441 Asia/Tokyo > --- >> JP,AU +353916+1394441 Asia/Tokyo Eyre Bird Observatory > > The Eyre Bird Observatory should probably be linked with an Australian time > zone instead of Asia/Tokyo. Actually that line should be OK, as the Eyre Bird Observatory region (unlike the rest of Australia) has observed Tokyo time since 1970. The comments at the start of zone1970.tab say this about the "Eyre Bird Observatory" in column 4: # Comments; present if and only if countries have multiple timezones, # and useful only for those countries. For example, the comments # for the row with countries CH,DE,LI and name Europe/Zurich # are useful only for DE, since CH and LI have no other timezones. "Eyre Bird Observatory" is useful only for AU, since JP has no other timezones; so this is another example of that column-4 idea.

4 4

Medovukha factory in Kazakhstan advances its clocks by 1/20 of a day
by Paul Eggert Jan. 21, 2025

Jan. 21, 2025

Last year's move to unify Kazakhstan into a single UTC+05 time zone is seeing some pushback. In "Anger over Kazakh Time Zones" (2024-12-24)[1] RFE/RL's Chris Rickleton and Tasqyn Bolatuly reported that one lawmaker asserted that a majority his party in parliament would support a law to reverse the decision. Although government executive officials still strongly support the move, we'll need to keep an eye on the situation. Rickleton and Bolatuly also reported how one private firm is addressing the problem: > Almas Tangytuli, the owner of a company that produces medovukha, a honey-based alcoholic drink similar to mead, says he is already doing something similar. > > After struggling with the new time, he set the clocks at his factory just east of Oskemen forward by a 1 1/5 hour for the sake of his workers, who keep livestock in villages nearby. > > "After work, there was no time for them to sort out their barns in the steppe, where there is no lighting. In the morning, their cattle make a rush for the fields. You can't tell cattle that the clocks have changed," Tangytuli told RFE/RL. 1 1/5 hour is 72 minutes, or 1/20 of a day. I wonder where Tangytuli got that number? Oskemen is about 5.5 hours ahead of UTC, so he has overcorrected and is about 0.7 hours ahead of local mean time; surely this is not entirely for the sake of the cows. The fractional hour vaguely reminds me of William Willett's 1907 proposal to implement daylight saving time by advancing clocks by 20 minutes each in four successive Sundays.[2] But although Willett wanted his construction workers to get to his worksites earlier during the day, he wrote nothing about his workers' cows. [1]: https://www.rferl.org/a/33249639.html [2]: https://www.webexhibits.org/daylightsaving/willett.html

1 0

Re: [tz-announce] 2025a release of tz code and data available
by Paul Eggert Jan. 21, 2025

Jan. 21, 2025

On 2025-01-16 11:21, Geert Hendrickx wrote: > On Thu, Jan 16, 2025 at 09:37:50 -0800, Paul Eggert via tz-announce via tz wrote: >> ... Paraguay adopts permanent -03 starting spring 2024. > > starting spring *2025* ? Actually, "spring 2024" is correct. Release 2025a says the legal change occurred in Paraguay on 2024-10-15 at 00:00, which is spring in the southern hemisphere. The clocks didn't change then: only tm_isdst changed, and since tm_isdst is obsolescent that wasn't enough to prompt a new TZDB release right away. The first change to predicted timestamps is this year on March 22 at 00:00, when Paraguay is now predicted to stay at -03 instead of falling back from -03 to -04. This will be autumn in the southern hemisphere.

1 1

[tz-announce] 2025a release of tz code and data available
by Paul Eggert via tz-announce Jan. 16, 2025

Jan. 16, 2025

The 2025a release of the tz code and data is available. This release contains the following changes: Briefly: Paraguay adopts permanent -03 starting spring 2024. Improve pre-1991 data for the Philippines. Etc/Unknown is now reserved. Changes to future timestamps Paraguay will stop changing its clocks after the spring-forward transition on 2024-10-06, so it is now permanently at -03. (Thanks to Heitor David Pinto and Even Scharning.) This affects timestamps starting 2025-03-22, as well as the obsolescent tm_isdst flags starting 2024-10-15. Changes to past timestamps Correct timestamps for the Philippines before 1900, and from 1937 through 1990. (Thanks to P Chan for the heads-up and citations.) This includes adjusting local mean time before 1899; fixing transitions in September 1899, January 1937, and June 1954; adding transitions in December 1941, November 1945, March and September 1977, and May and July 1990; and removing incorrect transitions in March and September 1978. Changes to data Add zone1970.tab lines for the Concordia and Eyre Bird Observatory research stations. (Thanks to Derick Rethans and Jule Dabars.) Changes to code strftime %s now generates the correct numeric string even when the represented number does not fit into time_t. This is better than generating the numeric equivalent of (time_t) -1, as strftime did in TZDB releases 96a (when %s was introduced) through 2020a and in releases 2022b through 2024b. It is also better than failing and returning 0, as strftime did in releases 2020b through 2022a. strftime now outputs an invalid conversion specifier as-is, instead of eliding the leading '%', which confused debugging. An invalid TZ now generates the time zone abbreviation "-00", not "UTC", to help the user see that an error has occurred. (Thanks to Arthur David Olson for suggesting a "wrong result".) mktime and timeoff no longer incorrectly fail merely because a struct tm component near INT_MIN or INT_MAX overflows when a lower-order component carries into it. TZNAME_MAXIMUM, the maximum number of bytes in a proleptic TZ string's time zone abbreviation, now defaults to 254 not 255. This helps reduce the size of internal state from 25480 to 21384 on common platforms. This change should not be a problem, as nobody uses such long "abbreviations" and the longstanding tzcode maximum was 16 until release 2023a. For those who prefer no arbitrary limits, you can now specify TZNAME_MAXIMUM values up to PTRDIFF_MAX, a limit forced by C anyway; formerly tzcode silently misbehaved unless TZNAME_MAXIMUM was less than INT_MAX. tzset and related functions no longer leak a file descriptor if another thread forks or execs at about the same time and if the platform has O_CLOFORK and O_CLOEXEC respectively. Also, the functions no longer let a TZif file become a controlling terminal. 'zdump -' now reads TZif data from /dev/stdin. (From a question by Arthur David Olson.) Changes to documentation The name Etc/Unknown is now reserved: it will not be used by TZDB. This is for compatibility with CLDR, which uses the string "Etc/Unknown" for an unknown or invalid timezone. (Thanks to Justin Grant, Mark Davis, and Guy Harris.) Cite Internet RFC 9636, which obsoletes RFC 8536 for TZif format. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2025a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2025a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2025a.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit a8e2fcd87bc5f83fec0a76652095e8d7881b0763 dated 2025-01-15 10:47:24 -0800 and tagged '2025a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 308f6a3d6ebfa18446f8296e5c799e18dccecd79ace3ba004d3f233892c7428faae152b217b22d229c59dd4e0faafee797d8b3583b58fa982b81f7cc7347f502 tzcode2025a.tar.gz 93b8f939d39bdfe451e262666f9099c529c96c49d14c08e3611560ca660e12e16d08a22b145d615e00570fb194881618d6f9a0a617c119ab447be03279d747c3 tzdata2025a.tar.gz 1e8c4e141158d63ca5c39babc9d18c32df14e2e59bc7649a7fed8c3e577f7b175bafa43883cf351139ff198515f5f8c22b1418e2ac7efb7f837faa8f61d2574d tzdb-2025a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2oACgkQ7ZfpDmKq fjT4TA//dFIBsmsl3OJ7QdI3lnySSQWyNnZQjsue3qtw7dUp0nbbFd7QGegrVDSC zrY+v51AVm9sk9hLdLQuyVFm5xRqXuBp2fC70wFeCCocEMp4HnhOogJVXMqQz+Dy AFZ8U7HmtNUI+ca9MTw6WTpQ5DOy6Of5rer3LbicmzBgVQ/UNcoIFZs4qf+RnMYY GKOHfLDLhs/4fQf3+zfELLbavieOoqcQlp8HntZrCuR2zZZNImVkt0/ljtTnHqd/ b0KUMDbYQ2dGsNbpBQS5GhAUjVPeUB5npqfA0ibS1gv1e99yWwGeMmUY3GqFbQWn dNN5LTceS9/H/+thtgN+70g4b2Haz+So91AiXKMNxgvb9qkjqV+2ZFd04ud4hapz +rRV8y1VDP/QEmXwL4zMnx+xkzGr3xTh+0z67R3RBIbL5eRGQojjKN1BLkYTWRsx VfaI51+GJWKjlX1Mo9OoSGGWgRWPgn591dYcep+cKA9jYSMzO48VOsdABIt3tTbX 7zqONqpDt6JZJJL7UdH2A0Lik8nkGFnSAnuuwW948CGh26odotoXAC15xWbK18VN v6T+zGZoLR8PdVlIYPjNUyS0sqo6tZtHa3Nci99+A5XG30oX+ecz/zlyDuRBLWkI 31bmm5423PHZ4N94Yi2V6xAC2G7mHn9m7eYv71C6Pg6fs5vOTgA= =2Ldn -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2oACgkQ7ZfpDmKq fjREhxAAjB1QDroFoq07V+56IIrJR3pK/x4Z2jBbg53N49Cam1oMZK5Wxm291d0G lPutNQvjiNubnBG4pgMMQ2xEF6jgYY0eFfLlORGK9IoW8e3lnlAqSR9BsOQvWjeA lKfmBkhFXetSJ8gu2ModVybpVIqDaJJ73sNQSsA01MHwz0RLV5CLOHXitJ8lBO68 vdSArRhalLUEIVytAKyy1a0msFdzrrDj/7q6tMV9NDY1xQg4V9TLxnPNds29H0x8 xO2zrDug6zrbg9z994JYkhq9h9DLe5h4F3StnaDwRK8eLLRq5D7ryK77Z8dtyXZf tDPgiNc1MquSg48481dDiUfsRdN5S2OLVFqjyWUuwVKBSkSRv/nBQqisGEybY86T H84D5WA0zlj8mFJyuKFmvGHzzKZ6X7mUNrTObaY3G+QHgHjIKWqO7oog447YOYOG DSA5rSmYrzZp2RXP/doeFZD+2kbNVPlN8zBh6lANABwvFH6IhDI+/OJzGJqeYotz ZWVoU3um6aToMS4Uv2PdBNbH1W1P1pzzMM5TJ/bQO/ujCwaBSTwoDPJT6tW9BLrO gJUWd1AumocieAWc0Vyzbrpzbo7Vc//1LF+s1eI+zWt8925unFrBArvQ4h/PyXsc O5LhOQVm1986y9xy2YyF+Cy5s+xsKvKENQ0NbLIDa+l5MdEdEXc= =NQgW -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2sACgkQ7ZfpDmKq fjQkcQ/+MWIjE3J5FETCaYxUvElzWIN25Jx4p3dBp4CL/UqD9qW/3CRiRt7KbS5Q 2C1+Hg5DKGAJJ/9/L72t4ttMheskUkGyI/M/xWuG2EKMRPJd3zEPZItSfJOtbBwo vmmTIe9s/yZTkmeoMQ/PVdhci6rwifwUEopxq3V2pTBIBnj6H+hBlSLL8Y7RgbWQ yDlzf1HvfnQ+4xlhtcDNb49iljlrPEwUJZe+2RSPmxAtAHe6SJK4i9tSQlv0fJew whM0//rlihNKRG04TFJ4lw5UeueCKhLL8E/HLbLewVcJcbd4pHMFNmdxi17VHmZj IG1tj75Ff69dyuZiCkuOe9S5SzKlI40FEU3aN1k7wWz3PzBbGBWt9CMxNY35DpLF Di23QeTOvdDEEccjivRVyNc4mwthnylOcmKcE5RYhT45W+Tpr0BhLnE29/ZwZ3Dy EB8wQJvGZWh6LVK2C7unEmQaYmPD+pl8WoZ9MmZHnR0YmNd/NfcefKX/UenLs5+J HIifuTWnzRfA4DQTbV+l/kNUzOo/asoD98qQ6/2inDEQWCZpg1V1sOFcHVYkb6XX LT7PUnC5eiKS8U47KBzTTwkEAWij/LKD+gnksjfkzU/Pn5MpzXm4qwVo7v9yuEal i4nIbqzuY8iK0SYBw0da8W10dFtB3bgtfUuSTXQLCP8sWVI34bY= =B68m -----END PGP SIGNATURE-----

1 0