April 2022 - tz - lists.iana.org

(no subject)
by Cool Gab19 Nov. 8, 2024

Nov. 8, 2024

can you add Philippine Daylight Time on your Database I think it was missing from the list of the time zones please reply immediately if solved thanks...

4 8

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert March 15, 2023

March 15, 2023

On 3/19/21 3:15 AM, Semlali Naoufal wrote: > At the moment, we have no official government announcement to this effect. But, logically, the change to the GMT schedule should be made on the night of April 10-11, 2021 (last weekend before Ramadan). Yes, that's been the tzdb prediction too, ever since tzdb version 2018h (2018-12-23). For the record, here are tzdb's current predictions Morocco transitions during the next five years. Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 Sun Mar 27 01:59:59 2022 UT = Sun Mar 27 02:59:59 2022 +01 Sun Mar 27 02:00:00 2022 UT = Sun Mar 27 02:00:00 2022 +00 Sun May 8 01:59:59 2022 UT = Sun May 8 01:59:59 2022 +00 Sun May 8 02:00:00 2022 UT = Sun May 8 03:00:00 2022 +01 Sun Mar 19 01:59:59 2023 UT = Sun Mar 19 02:59:59 2023 +01 Sun Mar 19 02:00:00 2023 UT = Sun Mar 19 02:00:00 2023 +00 Sun Apr 30 01:59:59 2023 UT = Sun Apr 30 01:59:59 2023 +00 Sun Apr 30 02:00:00 2023 UT = Sun Apr 30 03:00:00 2023 +01 Sun Mar 10 01:59:59 2024 UT = Sun Mar 10 02:59:59 2024 +01 Sun Mar 10 02:00:00 2024 UT = Sun Mar 10 02:00:00 2024 +00 Sun Apr 14 01:59:59 2024 UT = Sun Apr 14 01:59:59 2024 +00 Sun Apr 14 02:00:00 2024 UT = Sun Apr 14 03:00:00 2024 +01 Sun Feb 23 01:59:59 2025 UT = Sun Feb 23 02:59:59 2025 +01 Sun Feb 23 02:00:00 2025 UT = Sun Feb 23 02:00:00 2025 +00 Sun Apr 6 01:59:59 2025 UT = Sun Apr 6 01:59:59 2025 +00 Sun Apr 6 02:00:00 2025 UT = Sun Apr 6 03:00:00 2025 +01 Sun Feb 15 01:59:59 2026 UT = Sun Feb 15 02:59:59 2026 +01 Sun Feb 15 02:00:00 2026 UT = Sun Feb 15 02:00:00 2026 +00 Sun Mar 22 01:59:59 2026 UT = Sun Mar 22 01:59:59 2026 +00 Sun Mar 22 02:00:00 2026 UT = Sun Mar 22 03:00:00 2026 +01 Sun Feb 7 01:59:59 2027 UT = Sun Feb 7 02:59:59 2027 +01 Sun Feb 7 02:00:00 2027 UT = Sun Feb 7 02:00:00 2027 +00 Sun Mar 14 01:59:59 2027 UT = Sun Mar 14 01:59:59 2027 +00 Sun Mar 14 02:00:00 2027 UT = Sun Mar 14 03:00:00 2027 +01 Sun Jan 23 01:59:59 2028 UT = Sun Jan 23 02:59:59 2028 +01 Sun Jan 23 02:00:00 2028 UT = Sun Jan 23 02:00:00 2028 +00 Sun Mar 5 01:59:59 2028 UT = Sun Mar 5 01:59:59 2028 +00 Sun Mar 5 02:00:00 2028 UT = Sun Mar 5 03:00:00 2028 +01 Sun Jan 14 01:59:59 2029 UT = Sun Jan 14 02:59:59 2029 +01 Sun Jan 14 02:00:00 2029 UT = Sun Jan 14 02:00:00 2029 +00 Sun Feb 18 01:59:59 2029 UT = Sun Feb 18 01:59:59 2029 +00 Sun Feb 18 02:00:00 2029 UT = Sun Feb 18 03:00:00 2029 +01 Sun Dec 30 01:59:59 2029 UT = Sun Dec 30 02:59:59 2029 +01 Sun Dec 30 02:00:00 2029 UT = Sun Dec 30 02:00:00 2029 +00 Sun Feb 10 01:59:59 2030 UT = Sun Feb 10 01:59:59 2030 +00 Sun Feb 10 02:00:00 2030 UT = Sun Feb 10 03:00:00 2030 +01 Sun Dec 22 01:59:59 2030 UT = Sun Dec 22 02:59:59 2030 +01 Sun Dec 22 02:00:00 2030 UT = Sun Dec 22 02:00:00 2030 +00

3 9

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

Re: [tz] iana build failures on Windows
by Paul Eggert Nov. 2, 2022

Nov. 2, 2022

On 4/19/21 7:09 AM, Manuela Friedrich wrote: > I had to include signal.h in zic.c to prevent the following error: > > zic.c(610): error C2061: syntax error: identifier 'got_signal' This is a portability bug recently introduced to zic.c. I installed the first attached patch to fix it. > The I needed to resolved error > > zic.obj : error LNK2019: unresolved external symbol tz_time referenced in function random_dirent This appears to be another recent portability bug. It's related to a portability problem you reported on MS-Windows in response to which in 2018d I committed a patch that introduced RESERVE_STD_EXT_IDS: https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268 When I recently added the randomish filename code to the development version, I neglected to deal with RESERVE_STD_EXT_IDS. The second attached patch should fix this issue. Please give the two patches a try, as I don't use MS-Windows and can't easily test these patches on that platform. > a test run of zdump -v produced way more output than in the last release, the Linux output seems to have become longer too, but maybe this is still under development. That change is intentional, and was caused by this: https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351 along with some neighboring commits. Thanks for reporting the problems, and I hope the current development version of tzdb addresses the issues you mentioned.

5 23

question re zone America/Punta_Arenas in Chile
by Alois Treindl July 7, 2022

July 7, 2022

In 2016, Chile introduced a new time zone for it south-most province Magallanes, and for this reason a new zone Zone America/Punta_Arenas -4:43:40 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 2016 Dec 4 -3:00 - -03 has been created. before it followed Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1946 Jul 15 -4:00 1:00 -03 1946 Sep 1 # central Chile -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 The new zone differs from zone Santiago at two points: - it does not have the 1946/47 DST - it differs from 2016 Dec 4, the reason of its creation. I wonder on which basis the 1946/47 DST was left out for Puntas_Arenas? Is that documented somewhere? The main reason why I ask: My two sources Shanks and Gabriel have always claimed that zone America/Santiago is only good for the province of Santiago, but that the rest of Chile did not have DST between 1927 and 1932. This is why in my private pre-1970 TZ extension I have an extra zone for 'rest of Chile besides Santiago' Zone America/Chile/Antofagasta -4:41:36 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1932 Sep 1 0 follow America/Santiago which leaves out the 1927-1932 DST. It has however the 1946/47 DST. I have another zone, based on Shanks and Gabriel, for Vaparaiso, which leaves out the 1946/47 DST, but has a one-summer 1931/1932 DST. Zone America/Chile/Vina_del_Mar -4:46:16 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1931 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 0 follow America/Santiago Sadly, I have currently no sources for that beyond Shanks and Gabriel. We would need local newspaper archives from a non-Santiago newspaper for 1927-1932 to confirm. But it this is true, we have to assume that province Magellanes behaved like 'the rest of Chile' and not like Santiago before the split in 2016. That means that it should be: Zone America/Punta_Arenas -4:43:40 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 2016 Dec 4 -3:00 - -03

4 6

the tzdb information schema
by Michael H Deckers July 4, 2022

July 4, 2022

Some recent difficulties with tzdb updates have led me to consider how they could have been avoided. • The fact that two timezones agree since 1970 is not represented independently from the data of each timezone. This leads to "update anomalies" well-known from database theory. For instance, before Africa/Khartoum switched to UTC - 02 h in 2017, Africa/Juba was a link (in the file africa) to Africa/Khartoum. After the switch, new Zone data for Africa/Juba had to appear in the file africa. Actually, Zone data for Africa/Juba had survived in the file backzone but this was overlooked, so that we had Zone data for Africa/Juba in both files africa and backzone from 2017c until 2018b, and these Zone data did not even agree. And all this happened for Africa/Juba even though civil time in Juba was not changed at all at the time. It appears that this error would not have happened if all African Zone data had been kept in the file africa (rather than in africa and in backzone) -- it was not the Zone data of Africa/Juba that had changed, but only the fact that Africa/Juba ws merged with Africa/Khartoum because their Zone data agreed since 1970. Unfortunately, this fact was not (and still is not) representable as an independently changeable item in tzdb. • Most of the Zone data currently contained in the file backzone have in earlier versions been stored in the "continental" files (africa, antarctica, asia, australasia, europe, northamerica, southamerica), and the reason why they are in backzone is that their Zone data agree with other Zone data since 1970. And since this may well change in the future, we have to keep these Zone data in backzone current. The file backzone is an integral part of the tzdb data, not just a container for additional data of lesser quality. The quality of any Zone data (and any Rule data) in tzdb should always be "to the best of our current knowledge" -- it just does not make sense to keep Zone data in tzdb that are not updated when we acquire relevant new information for them. Thus we should get rid of Zone data for Argentina/Rosario etc (or else update them); keeping data that are known to be wrong is not only useless, it is an invitation for consequential errors. • Letting derived data (such as whether two timezones should be merged because they agree since 1970) decide about the storage location of the Zone data for a timezone not only implies unnecessary data moves upon data updates, it may also disrupt commentary text and its references. Easily understandable comments (such as which facts were deduced from which document) are crucial for later updates, where the effect of a newly found document has to be determined, often after several years, and likely by a different contributor. • The fact that two timezones agree since 1970 has nothing to do with the fact that some timezones have changed their names, with the old names being kept as Links to the new names. Currently, however, Links representing one or both facts are kept in the same file backward, and cannot be distinguished. This leads to information loss and update anomalies: Currently, the file backward has a Link from Africa/Asmera to Africa/Nairobi -- the information that Asmera is an outdated spelling of Asmara can only be found in the file backzone. The name America/Virgin had been replaced by America/St_Thomas in version 95k, and this fact could be seen in the file backward until 2021a when this information was lost. It reappeared (in backzone) only in version 2021c. Keeping one type of information (spelling changes) in different locations (files backward or backzone) depending on an independent condition (that may even change over time) certainly causes unnecessary maintenance effort. While some of these points may sound like theoretical claims for normal forms as taught in computer science, my point here is only practical simplicity: each basic fact to be recorded in tzdb should have its obvious place where it is stored and where it can be looked up and updated; and updates of independent facts should be possible without mutual side effects. This appears to be a necessity for a collaborative project. Last Saturday, Paul Eggert has very nicely summarized the history and some of the guiding principles of tzdb. It is largely due to his immense work on the maintenance and evolvement of tzdb that the tzdb system was such a tremendous success in its first 30 years. As a means for the success over the next 30 years, I propose a simplification of the tzdb schema, so as to avoid the update anomalies described above, and thus decrease the maintenance burden, currently mainly shouldered by Paul. The information schema used in the fork produced by Stephen Colebourne is already much simpler, and it is apparently what is needed by several power users contributing to the widespread success of tzdb. Michael Deckers.

2 1

Etc/GMT+nn and Etc/GMT-nn not working since zic 2021d
by Peter Krefting July 1, 2022

July 1, 2022

Hi! I am creating timezone data for an embedded device, and with space as a premium I run zic with the -r parameter to cut off all time change information from before the software release date, as this is not relevant for the system. Since commit 5f06f9a3182d2c2942be1b678e4defa9c7400653 (included in 2021d), this causes the Etc/GMT+xx and Etc/GMT-xx timezones not to work, they always report GMT ("-00"): ~ # TZ=Europe/Oslo date Mon Mar 21 13:08:32 CET 2022 ~ # TZ=Europe/London date Mon Mar 21 12:08:36 GMT 2022 ~ # TZ=Etc/GMT+1 date Mon Mar 21 12:08:43 -00 2022 ~ # TZ=Etc/GMT+2 date Mon Mar 21 12:08:45 -00 2022 This is particularly severe for our devices since previous versions of our software only supported UTC offsets, and these are automatically updated to these GMT+xx and GMT-xx timezones on update, so many of our customers are expected to have these zones configured. We are running with "-r cutoff -b fat", where cutoff depends on the release date, and the embedded software currenlty is using GNU libc 2.20. Reverting 5f06f9a3182d2c2942be1b678e4defa9c7400653 fixes the issue for us, but is probably not the correct approach. -- \\// Peter - http://www.softwolves.pp.se/

3 6

Kyiv not Kiev error
by Євген Доманський June 24, 2022

June 24, 2022

Dear All There is an error in name of the capital city of Ukraine - Kiev ('Київ' in Ukrainian language). Kiev is the transliteration of the city name from Russian language. The only correct transliteration is Kyiv. Please update the name. Best regards. *Yevhen Domanskyi* *Study Coordinator* Department of Oncology and Medical Radiology Dnipro State Medical University 31, Blyzhnya Str., Dnipro, 49102, Ukraine *Mobile*: +380 93 060 26 92 *e-mail: *dom.eugene(a)gmail.com Website: http://www.sitetv.net/ <http:/www.sitetv.net/>

11 26

Change Request: Europe/Kiev to Europe/Kyiv
by Oleksandr Leskiv June 23, 2022

June 23, 2022

The history of timezones has some existing cases where a specific timezone has been renamed. For example, the *Asia/Calcutta* timezone has been deemed obsolete and replaced by *Asia/Kolkata*. In Ukraine, according to international standards, there is a timezone called *Europe/Kiev*. The capital of Ukraine is officially and internationally should be spelled as "Kyiv". "Kiev" is an incorrect version that emerged a long time before the Soviet Union collapsed in 1991. We have a really large community of programmers that would like to start the process of renaming the Europe/Kiev timezone to Europe/Kyiv. We understand that it will take a long time for everybody to transition, but it has to be done in the long term. Sincerely, Oleksandr. TakeUsEat.

7 10

Wrong behaviour with truncated TZif files
by Almaz Mingaleev June 1, 2022

June 1, 2022

Hi Paul, I've built TZif files with following commands: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data # Truncate at 1 Jan 2100. ./zic -b fat -r "/@4102444800" -d ./data rearguard.zi make TZDIR="./data" all Then I've compiled attached file: g++ mktime_test.cpp localtime.o Test tries to find epoch timestamp for 2 Jul 1980 midnight at America/Los_Angeles. With a truncated TZif file it prints 331344000. With non-truncated one it prints 331372800. The latter is the right answer. Also, date command is wrong on certain time zones: make TZDIR="./data" date TZ=Antarctica/Palmer ./date -r -631152000 prints "Sat Dec 31 20:00:00 -04 1949" even though 1 Jan 1950 offset should be zero <https://github.com/eggert/tz/blob/df4699ddfc9caf6f875f1e38703dd0ef41826175/…> . Thanks, Almaz

2 7

Unexpected last transition in Africa/Casablanca
by Almaz Mingaleev May 19, 2022

May 19, 2022

Hi Paul, Here are the last transitions in Africa/Casablanca output (rearguard format): transition,type,[UTC time],[Type offset],[Type isDST] 3672612000,1,2086-05-19T02:00:00Z,PT1H,DST 3699828000,2,2087-03-30T02:00:00Z,PT0S,STD 3703456800,3,2087-05-11T02:00:00Z,PT1H,STD So change is from standard to standard, even though offset changes from 0h to 1h. Is that expected behaviour? As Africa/El_Aaiun is using Morocco rules, its transitions are also affected. This affects 64-bit section only, 32-bit section looks fine to me. Thanks, Almaz Data above is output of debug tools used in Android. The way I've built data an byte manipulations if needed: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data ./zic -b fat -d ./data rearguard.zi byte manipulations: Let's skip 32-bit header: xxd -seek 20 -c 4 -l 24 data/Africa/Casablanca typecnt: 94 timecnt: 5 charcnt: 12 32-bit block size = 94 * 4 + 94 + 5 * 6 + 12 = 512 64-bit start = 44 + 512 = 556 64-bit header: xxd -seek 576 -c 4 -l 24 data/Africa/Casablanca: timecnt: 196 typecnt: 4 <- 32-bit section has 5 charcnt: 12 transition types offset: 556 + 44 + 196 * 8 = 2168 xxd -seek 2168 -c 1 -l 196 data/Africa/Casablanca ... 00000934: 02 . 00000935: 01 . 00000936: 02 . 00000937: 01 . 00000938: 02 . 00000939: 01 . 0000093a: 02 . 0000093b: 03 . <- the last transition local time records offset = 556 + 44 + 196 * 9 = 2364 xxd -seek 2364 -c 6 -l 24 data/Africa/Casablanca 0000093c: ffff f8e4 0000 ...... 00000942: 0000 0e10 0104 ...... 00000948: 0000 0000 0008 ...... <- standard time 0000094e: 0000 0e10 0004 ...... <- also standard time

6 13

Updates on Iranian Time Zone (IRDT)
by Mohammad Ali Tofighi May 11, 2022

May 11, 2022

Hi. Recently the Iranian parliament has decided to remove daylight saving from the Iranian time zone, eliminating the one-hour shift in the summer time. Hence, it is always going to be UTC+3:30. *This is not their final decision yet* and there is a final confirmation to be made, but I just wanted to inform you about the update to prepare possible modifications. I'm a software engineer and if we have the update on *tzdata* package as soon as possible, the software companies can adjust themselves accordingly. Please read these official news: https://www.isna.ir/news/1400122419045/ https://www.yjc.news/00Xw0k Regards, Ali Tofighi

6 13

Changes to the tz database
by Shlomi Sasson May 1, 2022

May 1, 2022

hi, i opened this PR <https://github.com/rogierschouten/tzdata-generate/pull/11> on GitHub and I've been told I need to contact you, and specifically Paul Eggert, to fix it. The fix should replace the Ukrainian city Kiev with the official name Kyiv, put Kiev in the legacy zone and add Kyiv to a new zone (per Rogier Schouten <https://github.com/rogierschouten>) Can u pls help me fix that? -- Shlomi Sasson Engineering Group Manager, Bringg +972-52-4440986

3 4

Prague Astronomical Clock simulation
by Kerry Shetline April 21, 2022

April 21, 2022

While not precisely a timezone topic, I thought a simulation of the Prague Astronomical Clock might be of interest to the readers of this mailing list. I stumbled into this topic a few months ago and I find it fascinating. There aren't too many pieces of machinery that are over 600 years old and still running. Now, of course, it's not still all the original equipment in place today, and there has been a lot of downtime over the centuries as interest waxed and waned over keeping the clock running. Major components of the original clock, however, are still in service today. Having looked at other old astronomical clocks, the one in Prague, in my opinion, beats them all. For something first operational in 1410, it's a very ambitious and clever design that puts a lot of information into view all at once, in an attractive and compelling way: two different ways of counting the hours of the day, phases of the moon, position of the moon and the sun in the sky, sun rise and set times, and sidereal time. One of the things I discovered was Jan Tošovský's simulation of clock, which had some attractive SVG graphics, but a user interface that's a bit out of date and clunky by modern UI standards. I used his graphics as a starting point for my own simulation, which can now be found at https://orloj.org/orloj/. I received a lot of help and advice from Petr Král, the current "clock master", and founder of the Czech Horological Society, about the real, physical clock, its operation and history -- not to mention that he helped make sure my translation to Czech wasn't too far out of whack. By the way, if anyone takes a look at the site who speaks Spanish, French, or German, I'd love to hear about any suggestions for improved translations you might have. I used to do a lot of work in the past to make sure code was internationalizable, but this is my first multi-language Angular web application.

1 0

some problems with tzdata for Simferopol
by Michael H Deckers April 18, 2022

April 18, 2022

In version 2022a of the file "europe", we read for Simferopol: # The _Economist_ (1994-05-28, p 45) reports that central Crimea switched # from Kiev to Moscow time sometime after the January 1994 elections. # Shanks (1999) says "date of change uncertain", but implies that it happened # sometime between the 1994 DST switches. Shanks & Pottenger simply say # 1994-09-25 03:00, but that can't be right. For now, guess it # changed in May. 2:00 C-Eur EE%sT 1994 May # From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev. 3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s 3:00 1:00 MSD 1996 Oct 27 3:00s # IATA SSIM (1997-09) says Crimea switched to EET/EEST. # Assume it happened in March by not changing the clocks. 3:00 Russia MSK/MSD 1997 3:00 - MSK 1997 Mar lastSun 1:00u • The quoted text is inconsistent: The comment says that Simferopol uses Moscow time since 1994 May, but the Zone line "3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s" contradicts it (Moscow had other switching times between summer and winter times). Which is correct? • It is not clear what "IATA SSIM (1994/1997)" actually says. They probably do not specify the switching times expressed with the Zone line "3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s" or do they? • The Zone line "3:00 Russia MSK/MSD 1997" is redundant. Michael Deckers.

2 1

No permanent Maryland DST
by Arthur David Olson April 12, 2022

April 12, 2022

This year's regular session of Maryland's state legislature has ended. House Bill 126, establishing permanent Daylight Saving time (with contingencies) had been approved by the House of Delegates on a 108-24 vote; it was not approved by the Senate. We'll see what (if anything) happens at the national level. @dashdashado

1 0

Re: [tz] Wrong name of timezone
by Pierpaolo Bernardi April 11, 2022

April 11, 2022

Il giorno 25 ottobre 2021, alle ore 16:58, Igor Melnyk via tz <tz(a)iana.org> ha scritto: >But Ukraine has the Ukrainian language and Kiev is in russian language. The correct name of the capital city of Ukraine is Kyiv. Kiev is English language, as every other name in the db, not russian. It is only a coincidence that the English name is more similar to russian than to Ukrainian.

6 5

Timekeeping videos
by Tim Parenti April 5, 2022

April 5, 2022

A pair of time-related videos in my recommendations today, Monday 2022-04-04: At 16:00 BST (+01), Tom Scott published a video called "How does Britain know what time it is?" about the radio time broadcasts from the UK's National Physical Laboratory, which disseminates UTC(NPL). https://www.youtube.com/watch?v=yqciKS_N0K8 Typical of his attention to detail, the wall clock Tom holds continues to tick true to time throughout the entire video, even as it cuts away to interview shots and B-roll. A couple hours later, at 18:00 BST, the British comedy panel quiz show "QI" published a clip of their episode "Rude", originally aired 2020-05-28, in which the panel discusses, among other things, how Denmark hasn't updated its laws to officially use UTC instead of Mean Solar Time. https://www.youtube.com/watch?v=jRMD9LRmRA4 -- Tim Parenti

1 0

[Confirmation] America/Punta_Arenas will keep UTC -3 "indefinitely"
by Juan Correa April 3, 2022

April 3, 2022

Hello everyone: As almost all Continenal Chile just jumped back to UTC -4; I found there was a decree published last Thursday that will keep Magallanes region to UTC -3 "indefinitely" The decree is available at https://www.diariooficial.interior.gob.cl/publicaciones/2022/03/31/43217-B/… ; and it's a modification of Decreto 1286/2018 Its only paragraph say: "Nevertheless the aforementioned, the change of the Chile Continental Official time for Magallanes and Antártica Chile region will be extended indefinitely; and will be permanently set to GMT (sic) -3" -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

2 1

zone file format very strict
by Alois Treindl April 1, 2022

April 1, 2022

Hi I noticed that the last line of a zone file like # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Kabul 4:36:48 - LMT 1890 4:00 - +04 1945 4:30 - +0430 does not suffer a trailing TAB character, behind the +0430 I think the zone file compiling mechanism could be a bit more tolerant of trailing white space. The issue came about because I employ a zone file generator utility, which accidentally created such trailing tabs in some cases. I fixed my generator, but wanted to mention this anyway.

2 2

TZDB talk tomorrow at LibrePlanet 2022
by Paul Eggert April 1, 2022

April 1, 2022

Tomorrow, March 19, at 21:15–22:00 UTC (17:15–18:00 US Eastern time) I plan to deliver a talk "TZDB and some challenges of long data" at the all-online LibrePlanet 2022 conference. LibrePlanet is a conference about software freedom, happening on March 19–20, 2022. The event is hosted by the Free Software Foundation, and brings together software developers, law and policy experts, activists, students, and computer users to learn skills, celebrate free software accomplishments, and face upcoming challenges. Newcomers are welcome, and LibrePlanet 2022 will feature programming for all ages and experience levels. You can register for the conference in advance at <https://my.fsf.org/civicrm/event/info?reset=1&id=99>.

6 6