December 2023 - tz - lists.iana.org

Time Zone Database
by EL MAAYATI Afaf July 8, 2026

July 8, 2026

Dear Paul, I'm Afaf EL MAAYATI from National Telecommunications Regulatory Agency in Morocco. Actually, in the current version of Time Zone Database (https://www.iana.org/time-zones) for Africa region, and especially for Morocco, it’s mentionned that a program will be running to implement the transition dates. According to this program, the next transition dates (during 2023) are as below : - March 19, 2023 (switching to GMT). - April 30, 2023 (switching back to GMT+1). In fact, we will switch back to GMT+1, advancing 60 minutes, on Sunday, April 23 at 2:00 a.m (not on April 30). Please refer to the official annoncement, published by the Ministry of Digital Transition and Administration Reform: https://www.mmsp.gov.ma/fr/actualites/passage-%C3%A0-l%E2%80%99heure-gmt-%C… So, would you please update the program, in order to consider « April 23 at 2:00 a.m » (for switching back to GMT+1). Thank you in advance for your feedback and for your habitual support. Thank you. Best Regards, Afaf EL MAAYATI National Telecommunications Regulatory Agency Morocco [https://www.anrt.ma/images/ANRT-Signature.jpg] ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.

2 6

(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] Time for a Lunar time zone? -Brooks
by Paul Eggert July 11, 2024

July 11, 2024

On 3/2/23 09:51, Brooks Harris wrote: > Will we need DST on the Moon? :-) I hope not! The Moon's axis tilts only 1.5°, much less than the 23.5° of Earth's axis, so seasonal effects on sunlight duration are much less intense on the Moon and there should be less need for Earth-like DST. A more pressing issue is that the length of day (including daytime and nighttime) varies more on the Moon. Local Earth days vary by at most 0.008 hours from the mean of 24 hours (this variation is due to the eccentricity of the Earth orbit and the obliquity of the ecliptic). So people who think that every local Earth day is exactly 24 hours are not far off. Local lunar days, in contrast, are roughly 29.5 ± 0.25 Earth days (again, this includes both lunar daytime and lunar nighttime). That's more slop to deal with, relatively speaking, and dealing with varying-length days could be a bit of a problem for civil time on the Moon. Presumably ESA's boffins are on top of this.....

4 5

Ministry of Digital Development and Communications, the Government of Mongolia
by fr Jan. 7, 2024

Jan. 7, 2024

Dear Sir/Ma'am, As we sent an inquiry regarding the switching time to the regular summer time matter earlier, could you please provide us some recommendations on below. The Government of Mongolia is planning to switch to the regular summer time from 22-26 March, 2024. Currently, the discussions are made within the Government as well as at the Parliament. We expect that final decision will be made in the October. Therefore, is it possible to arrange the switching process in the next 5 months? Is there any extraordinary cases like us or not? Or shall we make our changes in the September 2024? Thank you for your kind consideration in advance and hope to hear from you soon. Sincerely, Ms. Ariuntuul --- Foreign Cooperation Division Ministry of Digital Development and Communications The Government of Mongolia Tel: +976 51 260636 www.mddc.gov.mn

4 4

Possible zic bug in far future calculations?
by Gilmore Davidson Dec. 30, 2023

Dec. 30, 2023

I was compiling the 2023d release for the Moment Timezone JS library and noticed some oddities in the diff of the generated files. A lot of tests are auto-generated from the data for each tzdb release, making sure the library correctly handles each transition defined in `zdump` output. For 2023d, a handful of zones in North America added a lot more transition tests after the year 2400. These transitions were apparently missing in earlier releases, and appear to have been fixed by commit 35c116b7 ("Fix zic bug with Palestine after 2075"), which makes sense. But a strange case I noticed is specific to `America/Ciudad_Juarez`. In 2023c its overall zdump output ended at 2422, not 2499 like other zones. In 2023d zdump does go to 2499, but there's now a weird set of transitions in 2422. Compiling zic/zdump for 2023c and getting the data for 2421-2423: $ /tmp/tz/2023c/git/zdump -V -c2421,2424 /tmp/tz/2023c/zic/America/Ciudad_Juarez /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 14 08:59:59 2421 UT = Sun Mar 14 01:59:59 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 14 09:00:00 2421 UT = Sun Mar 14 03:00:00 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 7 07:59:59 2421 UT = Sun Nov 7 01:59:59 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 7 08:00:00 2421 UT = Sun Nov 7 01:00:00 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 13 08:59:59 2422 UT = Sun Mar 13 01:59:59 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 13 09:00:00 2422 UT = Sun Mar 13 03:00:00 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 6 07:59:59 2422 UT = Sun Nov 6 01:59:59 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 Doing the same for 2023d: $ /tmp/tz/2023d/git/zdump -V -c2421,2424 /tmp/tz/2023d/zic/America/Ciudad_Juarez /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 14 08:59:59 2421 UT = Sun Mar 14 01:59:59 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 14 09:00:00 2421 UT = Sun Mar 14 03:00:00 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 7 07:59:59 2421 UT = Sun Nov 7 01:59:59 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 7 08:00:00 2421 UT = Sun Nov 7 01:00:00 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 13 08:59:59 2422 UT = Sun Mar 13 01:59:59 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 13 09:00:00 2422 UT = Sun Mar 13 03:00:00 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 07:59:59 2422 UT = Sun Nov 6 01:59:59 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:01 2422 UT = Sun Nov 6 02:00:01 2422 CST isdst=0 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Wed Nov 30 05:59:59 2422 UT = Tue Nov 29 23:59:59 2422 CST isdst=0 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Wed Nov 30 06:00:00 2422 UT = Tue Nov 29 23:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 12 08:59:59 2423 UT = Sun Mar 12 01:59:59 2423 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 12 09:00:00 2423 UT = Sun Mar 12 03:00:00 2423 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 5 07:59:59 2423 UT = Sun Nov 5 01:59:59 2423 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 5 08:00:00 2423 UT = Sun Nov 5 01:00:00 2423 MST isdst=0 gmtoff=-25200 Note that consecutive seconds on Nov 6 2422 go MDT -> MST -> CST, then back to MST on Nov 30. (For diagnostic purposes... I'm running these tests on macOS 14.2.1 with default `make` and `make install`, no extra flags.) I don't particularly care about (or believe) the accuracy of the data that far in the future, but the wonky transitions make me think there's a bug lurking in zic that might affect other transitions at some point, if the conditions are right. I found it interesting that the data previously cut off exactly 400 years after the zone's last defined "until" rule in `northamerica`. Digging further, the other zones that had incomplete data follow the same pattern: `America/Indiana/Petersberg` ended in 2407 (last defined "until" in 2007). `America/Indiana/Vincennes` the same. `America/North_Dakota/Belulah` ended in 2410 (last defined "until" in 2010). These other zones don't appear to have the same consecutive transition problem (i.e. they're not buggy any more), but the 400 year pattern is telling. Cheers, Gil

2 2

More than 2 transitions per year for Asia/Gaza & Hebron in 2068+
by Dave Rolsky Dec. 30, 2023

Dec. 30, 2023

Hi all, With the latest release (2023d) I'm seeing some surprising output from zdump for the Asia/Gaza & Asia/Hebron zones: $> zdump -v Asia/Hebron ... Asia/Hebron Fri Mar 23 23:59:59 2068 UT = Sat Mar 24 01:59:59 2068 EET isdst=0 gmtoff=7200 Asia/Hebron Sat Mar 24 00:00:00 2068 UT = Sat Mar 24 03:00:00 2068 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 19 22:59:59 2068 UT = Sat Oct 20 01:59:59 2068 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 19 23:00:00 2068 UT = Sat Oct 20 01:00:00 2068 EET isdst=0 gmtoff=7200 Asia/Hebron Fri Mar 29 23:59:59 2069 UT = Sat Mar 30 01:59:59 2069 EET isdst=0 gmtoff=7200 Asia/Hebron Sat Mar 30 00:00:00 2069 UT = Sat Mar 30 03:00:00 2069 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 11 22:59:59 2069 UT = Sat Oct 12 01:59:59 2069 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 11 23:00:00 2069 UT = Sat Oct 12 01:00:00 2069 EET isdst=0 gmtoff=7200 This pattern of >2 transitions per year continues from that year. Is this correct? It seems awfully weird. Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch

3 5

[tz-announce] 2023d release of tz code and data available
by Paul Eggert via tz-announce Dec. 22, 2023

Dec. 22, 2023

The 2023d release of the tz code and data is available. This release contains the following changes: Briefly: Ittoqqortoormiit, Greenland changes time zones on 2024-03-31. Vostok, Antarctica changed time zones on 2023-12-18. Casey, Antarctica changed time zones five times since 2020. Code and data fixes for Palestine timestamps starting in 2072. A new data file zonenow.tab for timestamps starting now. Changes to future timestamps Ittoqqortoormiit, Greenland (America/Scoresbysund) joins most of the rest of Greenland's timekeeping practice on 2024-03-31, by changing its time zone from -01/+00 to -02/-01 at the same moment as the spring-forward transition. Its clocks will therefore not spring forward as previously scheduled. The time zone change reverts to its common practice before 1981. Fix predictions for DST transitions in Palestine in 2072-2075, correcting a typo introduced in 2023a. Changes to past and future timestamps Vostok, Antarctica changed to +05 on 2023-12-18. It had been at +07 (not +06) for years. (Thanks to Zakhary V. Akulov.) Change data for Casey, Antarctica to agree with timeanddate.com, by adding five time zone changes since 2020. Casey is now at +08 instead of +11. Changes to past tm_isdst flags Much of Greenland, represented by America/Nuuk, changed its standard time from -03 to -02 on 2023-03-25, not on 2023-10-28. This does not affect UTC offsets, only the tm_isdst flag. (Thanks to Thomas M. Steenholdt.) New data file A new data file zonenow.tab helps configure applications that use timestamps dated from now on. This simplifies configuration, since users choose from a smaller Zone set. The file's format is experimental and subject to change. Changes to code localtime.c no longer mishandles TZif files that contain a single transition into a DST regime. Previously, it incorrectly assumed DST was in effect before the transition too. (Thanks to Alois Treindl for debugging help.) localtime.c's timeoff no longer collides with OpenBSD 7.4. The C code now uses _Generic only if __STDC_VERSION__ says the compiler is C11 or later. tzselect now optionally reads zonenow.tab, to simplify when configuring only for timestamps dated from now on. tzselect no longer creates temporary files. tzselect no longer mishandles the following: Spaces and most other special characters in BUGEMAIL, PACKAGE, TZDIR, and VERSION. TZ strings when using mawk 1.4.3, which mishandles regular expressions of the form /X{2,}/. ISO 6709 coordinates when using an awk that lacks the GNU extension of newlines in -v option-arguments. Non UTF-8 locales when using an iconv command that lacks the GNU //TRANSLIT extension. zic no longer mishandles data for Palestine after the year 2075. Previously, it incorrectly omitted post-2075 transitions that are predicted for just before and just after Ramadan. (Thanks to Ken Murchison for debugging help.) zic now works again on Linux 2.6.16 and 2.6.17 (2006). (Problem reported by Rune Torgersen.) Changes to build procedure The Makefile is now more compatible with POSIX: * It no longer defines AR, CC, CFLAGS, LDFLAGS, and SHELL. * It no longer uses its own 'cc' in place of CC. * It now uses ARFLAGS, with default specified by POSIX. * It does not use LFLAGS incompatibly with POSIX. * It uses the special .POSIX target. * It quotes special characters more carefully. * It no longer mishandles builds in an ISO 8859 locale. Due to the CC changes, TZDIR is now #defined in a file tzfile.h built by 'make', not in a $(CC) -D option. Also, TZDEFAULT is now treated like TZDIR as they have similar roles. Changes to commentary Limitations and hazards of the optional support for obsolescent C89 platforms are documented better, along with a tentative schedule for removing this support. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2023d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2023d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2023d.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 cc48c2dfa2f3c21d25ab108bba978b0307ecf0e8 dated 2023-12-21 20:02:24 -0800 and tagged '2023d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3994a5a060a7a5fffc6585f5191cf7679f9f9be44dbcee4d67d0e42c5b6020c308cb55caf8bf8d51554697665105a174cb470c8c4fc069438350f3bac725709b tzcode2023d.tar.gz 81832b2d738c28cecbcb3906cc07568c5ae574adc9de35b25d4bf613581c92d471d67213b4261a56f0ec02efcf211b4e298b7e1dc367c972e726b0a2e9498df4 tzdata2023d.tar.gz 334f02e20d5841e60ddbdbf074f231c1564c9ac7781bad8c9813e3045d3ea0422acd1caa23a63466ca6113c396d701ccbef29669749ae844d218e4e601a9ee02 tzdb-2023d.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmWFCxgACgkQ7ZfpDmKq fjQjkhAAuWOz1EC8Wo3ug3fU4ns0KJIk7fTV6yNKUGrjuxOmc15+Dxb8QtLKagTr 9bZBsnI1v3krgMclbuEirbkeacST0rnKbW0Dije20ZZXYUaDQ3J3nGbjOSfcnLNk dYODCQKVarkbZ70+mmm4ytvwpuQDY5W/WcP/8qXB+wTQQukAGHlglDEcdQKIwz1L aMqGzO6hd5Wv/mw0Nz16BIoEqntKLzSJE3h5h92lBhVA0em02jSrTzBZePW9k3qb VG9qjui5nrWW4nJZln15XKBz7omo7e+NEP9UFzvCWTgwKQkdGNMbTjj6cBh8wKMX SPgCBvHyGx2UzukdxXzzCEn471Ug1XNHJAAfvlEd3FkrPcUc5Hj7w0chKYibQTsm LrjUSzbIVX5EBIxEDaGWrDbahLsaw+w+Ui09nFZ/sSB1LcbCa9eGsYGHvicnBu2S RZhZWk7lL8rtQjFjOMeoLy5j3rX8zwE07BNgjmnfkxGkZJ7XdriWy937d5SLvkKN /gaaaJ/32NDzTdzkhdOLcqKi+x2wCODCNDThfM4JiOIzCFkeSlaYnqShW7CcV/9c Nh9VM9zLKkApqL9Mr/kPqT5+FmN6GunMK3y9qNwA8ROq7DpAgUWoc4ZGoeNYy5I9 XbSk2ua/gAFfJsubjZ56//eEgFsLOLcE2eyFpS0WPcIA9qVk+Jc= =ZPDg -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmWFCxkACgkQ7ZfpDmKq fjRuUxAAoioAZhZkP9DnoNvoo2YG+g4gxS4GIIw1KK6nhZqIN8F9e4wrvw6/++x/ 7FNP2+KV7ObTNlqeONv2niAL8zuFq8VhkN60D4j1qEu9H21Wxp6HFWOFEWi8l5TS l6dp4S1Rb5LmCVlbj2MbrbE6Qc+QptSdGuw12MQR34b5F8pX39vt+edMfHvA2lw0 KhMkELOaBhKCAoiVHC8onUZvCg5qEpynQ88LpKgnLWslT9fcU3m0mCuiXldSn5kp KppIlAFp6WuaKIJiuj61gjH9Py00PM7ww1+0eZbnbametmM3E2Or+YoP1pm5bIy8 77+iVCvBu+B1aW/cC1h2k3vLRUg8sFxMvGJdpow6JN1D+2e3Flk8+A8DPwRXtCRV yjjGOzIltbWwD7fisPKbvXSrVlQmMrNLMoyQcljZbYUa5nhTMoCiv+yed/DzG2ZF pwAJguKenamOiRpChFfkrVXBn/AWr4G7FVAogckFClz7qP6KSekJ0h1MzUw31c5g 8XZEwXNO2RGLbhgCw5uLg3V2KUvurSYGSBB46TnMNBLz1xRNelzkJ7XvJVIhxCEN L1t32v4jbD4YtXHqNugVId9uY3x8ed8SPdFy+8C2OqKY0TiWOTiAH2rz3vcz2L6O rsubE+4g/LUQI0fS9hTcabD9RcsP3k3/h2fZYLORM6frwuZA82U= =ylD7 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmWFCxoACgkQ7ZfpDmKq fjQiug//UW82Sq338kOG4pKEgEjoinNowfqA0cb5yZgg/wI9KKm3MSd2DqVOpySI MUwLzE2mqopxLsqrg+erdAgnaw67UqE7nkWui9zKYaON4D6XkwnFEyJTwefYzEUu WevUIMDreoK20ifcCYRNyvjFU6ik0MUVq1E5EZcli5yip4E7MRNQfiLemEe65shr ivUXndETTY06kLCf8Os7MyPxrrFc1IBB8f8fuRXcIgqqBRO+2YeViIh8iIbWIImF lO4S3Knh8Pd+6fOG5AGUcD8V7h5mZhFOVhTaKy6EWvU/98SZdGRIfszeHmgLCKmq CdKCO1K8XOITkqSWCenfTXnNELm/hsnuGPBcaRBxWXFNVLBaSaufmw0+h5IsviCo DwMqp3z7byOlNwYqeF+bYCXaoJ5ZATjCK82D5xKGLPs394/f6m46XEcQR9AU2JUR N59J0smHiH9lNzEuIcM7S8Rwwm05uVNUdHBubkz4YEWeruT5ZNlhRUnfq63Vv4ol UN5Lwqqew5V5kXmKueBHd5czN65z96EVsJTs9xMuS2OR2uekCmtqaYKhpL5DsFPH xcaAADZ1BvR2BJUmMSyXT/slyEjyK8I20irZaBGfSmAiHp9o2AW3K1pXLAXasa4E K+OAFiIqtuH7zGOIcDcj8A50KD//70nn8DPgk9S1HuQ4uTKcXBg= =IyqX -----END PGP SIGNATURE-----

1 0

Re: [tz] Antarctic research base Vostok local time
by Paul Eggert Dec. 22, 2023

Dec. 22, 2023

Unfortunately, it doesn't suffice to know just the current UTC offset. We would need to know the past UTC offsets back to at least 1970, and also to know when the base was and wasn't inhabited during that period. And we need citations to sources for this information.

3 5

Re: [tz] Definition of "timezone"
by Paul Eggert Dec. 22, 2023

Dec. 22, 2023

On 2023-12-21 07:08, ApoY2k wrote: > do you (or your > peers on the tz project) consider a "timezone" to be inherently tied to the > real-world geographical features they are used for, or is the word > "timezone" in this context more broader understood as "any 'Zone' entry in > the tzdb" - which would e.g. also denote "Etc/UTC" as a "real timezone". I'll cc this to tz(a)iana.org to see what others think. There's no formal definition. In TZDB commentary I tend to use "timezone" roughly as a synonym for "TZ setting", that is, for valid values of the TZ environment variable. In that sense there is a huge number of timezones since this includes POSIX TZ strings, and "Europe/London", "Etc/UTC" and "GMT0BST,M3.5.0/1,M10.5.0" all denote timezones. In contrast, the TZDB commentary uses "time zone" for the more common understanding in the real world, that is, the maximal-sized geographical region where clocks currently all have the same reading. In that sense there are 37 time zones right now, though the number changes depending on when you ask the question. The TZDB commentary doesn't use a name for the concept you're asking about, but I suppose "geographical timezone" would do. Admittedly the terminology is not always clear in this area. PS. I got the number "37" as follows: $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", "TZ", "time", or "now". 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) coord - I want to use geographical coordinates. 12) TZ - I want to specify the timezone using the POSIX TZ format. 13) time - I know local time already. 14) now - Like "time", but configure only for timestamps from now on. #? 14 The system says Universal Time is Thu Dec 21 20:00. Assuming that's correct, what is the local time? 1) Thu Dec 21 09:00 14) Thu Dec 21 20:00 27) Fri Dec 22 04:00 2) Thu Dec 21 10:00 15) Thu Dec 21 21:00 28) Fri Dec 22 04:45 3) Thu Dec 21 10:30 16) Thu Dec 21 22:00 29) Fri Dec 22 05:00 4) Thu Dec 21 11:00 17) Thu Dec 21 23:00 30) Fri Dec 22 05:30 5) Thu Dec 21 12:00 18) Thu Dec 21 23:30 31) Fri Dec 22 06:00 6) Thu Dec 21 13:00 19) Fri Dec 22 00:00 32) Fri Dec 22 06:30 7) Thu Dec 21 14:00 20) Fri Dec 22 00:30 33) Fri Dec 22 07:00 8) Thu Dec 21 15:00 21) Fri Dec 22 01:00 34) Fri Dec 22 08:00 9) Thu Dec 21 16:00 22) Fri Dec 22 01:30 35) Fri Dec 22 09:00 10) Thu Dec 21 16:30 23) Fri Dec 22 01:45 36) Fri Dec 22 09:45 11) Thu Dec 21 17:00 24) Fri Dec 22 02:00 37) Fri Dec 22 10:00 12) Thu Dec 21 18:00 25) Fri Dec 22 02:30 13) Thu Dec 21 19:00 26) Fri Dec 22 03:00 #?

5 8

[PROPOSED] * zonenow.tab: Explain comments column.
by Paul Eggert Dec. 21, 2023

Dec. 21, 2023

--- zonenow.tab | 3 +++ 1 file changed, 3 insertions(+) diff --git a/zonenow.tab b/zonenow.tab index aea2a90e..2dbe8f00 100644 --- a/zonenow.tab +++ b/zonenow.tab @@ -16,6 +16,9 @@ # first by standard time UTC offset; # then, if DST is used, by daylight saving UTC offset; # then by time zone abbreviation. +# 4. Every timezone has a nonempty comments column, with wording +# distinguishing the timezone only from other timezones with the +# same UTC offset at some point during the year. # # The format of this table is experimental, and may change in future versions. # -- 2.43.0

1 0