February 2024 - tz - lists.iana.org

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

Nov. 7, 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

error Portugal 1980
by Alois Treindl July 1, 2024

July 1, 2024

I think there is an error in TZ, regarding begin of DST in Portugal in 1980. A user of my website pointed it out. file europe has > Rule Port 1978 only - Oct 1 0:00s 0 - > Rule Port 1979 1982 - Sep lastSun 1:00s 0 - > Rule Port 1980 only - Mar lastSun 0:00s 1:00 S > Rule Port 1981 1982 - Mar lastSun 1:00s 1:00 S > Rule Port 1983 only - Mar lastSun 2:00s 1:00 S But Observatório Astronómico de Lisboa http://oal.ul.pt/hora-legal/legislacao-sobre-a-hora-legal/ has in document Tabela com a definição anual da Hora Legal portuguesa desde 1911 https://oal.ul.pt/documentos/2018/01/hl1911a2018.pdf > 1980 Hora do meridiano de Greenwich até à 1 hora do dia 6 de Abril, > instante > em que foi adiantada de 60 minutos, tendo-se regressado à hiora do meri- > diano de Greenwich às 2 horas do dia 28 de Setembro (Portaria nº 69/80) > I attach a patch file

4 12

Happy Leap Day...
by Arthur David Olson March 1, 2024

March 1, 2024

...to those who celebrate; Happy March 0 to those who don't. @dashdashado

4 3

NZ Leap Day Self Pay Petrol Pump Failures
by Brian Inglis March 1, 2024

March 1, 2024

https://arstechnica.com/gadgets/2024/02/leap-year-glitch-broke-self-pay-pum… -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

7 9

Administrivia: Mailing List Archives
by Kim Davies Feb. 25, 2024

Feb. 25, 2024

Hi all, We’ve done a little bit of work to fix some old corrupted email messages in the mailing list archive at http://mm.icann.org/pipermail/tz/. They’ve been corrupted ever since they were originally imported over a decade ago, but were noticed by an astute reader recently. Also, some of the historical links were broken for roughly the last three weeks for an unrelated reason, but these should work as expected now. If you notice anything awry please let me know. kim

2 1

leap-seconds.list format
by Byron Torres Feb. 19, 2024

Feb. 19, 2024

Good day, I write here to you knowledgeable people in the hopes you can clarify some things regarding the format of leap-seconds.list file. Please forgive me if there is a more appropriate place to ask. Recently it seems the IERS has changed the format of the leap-seconds.list file they serve[1], from the old format by NIST[2]. The comments are reworded, the lines wrap at a large width, and most importantly, the whitespace between the decimal timestamps and time-differences, previously a tab, have been replaced with spaces. [1] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list [2] ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list This, coupled with the fact that the tz repository recently began fetching from this source (I understand that is because the NIST source was flaky), has broken a leap-seconds.list parser[3] used by the standard library of the Hare systems programming language[4], a language akin to a modern C. I'm the maintainer of the Hare stdlib date/time subsystem[5]. [3] https://git.sr.ht/~sircmpwn/hare/tree/d0c057dbbb0f1ee9179769e187c0fbd3b0032… [4] https://harelang.org/ [5] https://harelang.org/who For context, Hare sources leap-seconds.list for UTC-TAI leapsecond data and implements timescales like UTC, TAI, GPS, etc. Hare could source from a TZIF file specified by $TZ, but the decoupling of timezone and leapsecond data allows for multi-timescale programming. We are working to improve Hare and to begin stable quarterly releases, so we ideally want guarantees for how leap-seconds.list is formatted. My questions are: * What was the motivation for the changes in IERS'es leap-seconds.list file? Is there a record of discussion regarding this? * What was the motivation specifically for the spaces-to-tab change? Did another commonly used software implement a forgiving parser? * What is the history of the leap-seconds.list file and file format? * Is the format for leap-seconds.list defined? Where and how strongly? * If there is no strong, formal definition, would a formal definition of the leap-seconds.list file format be welcome? To whom could I coordinate with? * Could at least the spaces be changed back to tabs? Personally, I do not like the idea of a make-time conversion script. It would be ideal for the source file to make this change, but before I email the contact mentioned in the new file, I thought to prod here first. Timely regards, b

5 20

timezone-related error sparks $340 million lawsuit
by Paul Eggert Feb. 18, 2024

Feb. 18, 2024

In "US man sues Powerball lottery after being told his apparent $340m win was error"[1], Maya Yang reported in today's Guardian that a mistake caused by a quality-assurance team checking timezone configuration for a Powerball lottery website has snowballed into a $340 million lawsuit against the lottery. Due to the mistake, in which a test version of the website was loaded with random numbers, the lottery's production website temporarily displayed the wrong winning numbers. A man whose ticket matched those numbers is now suing the lottery for the $340 million prize, saying he is the rightful winner. Yang reported that the errant QA team was testing "a task involving a changing of time zones for the Powerball website from Coordinated Universal Time to Eastern Standard Time." [1]: https://www.theguardian.com/us-news/2024/feb/18/man-sues-powerball-lottery-…

1 0

Checked arithmetic bug
by Dag-Erling Smørgrav Feb. 16, 2024

Feb. 16, 2024

In at least one instance around line 1187 of localtime.c, the code assumes that increment_overflow_time() does not modify the result if the operation overflowed, but that is not true when using C23 checked arithmetic. Details: https://bugs.freebsd.org/276281, particularly comment 11. One possible solution is attached. I'm not overly fond of it because it penalizes the common case, but it was easier than trying to understand and reformulate the loop in tzparse(). DES -- Dag-Erling Smørgrav - des(a)des.no

2 1

the Republic of Kazakhstan
by ЕЛИКБАЕВ КУАНЫШ НУРЛАНОВИЧ Feb. 5, 2024

Feb. 5, 2024

Dear colleagues, Technical Regulation and Metrology Committee of the Ministry of Trade and Integration of the Republic of Kazakhstan (CTRM) takes this opportunity to express its assurances of the highest consideration. CTRM participates in the implementation of strategic functions of the Ministry in the areas of technical regulation and Metrology. CTRM informs that by the Decree of the Government of the Republic of Kazakhstan dated January 19, 2024 No. 20, amendments have been made to the Decree of the Government of the Republic of Kazakhstan dated November 23, 2000 No. 1749 «On the procedure for calculating time on the territory of the Republic of Kazakhstan» (https://zan.gov.kz/client/#!/doc/192700/rus) which provides, among other things, for the Akimats of the cities of Astana, Almaty, Shymkent, Akmola, Almaty, Zhambyl, Karaganda, Kostanay, Pavlodar, North Kazakhstan, Turkestan, East Kazakhstan regions and Abay, Zhetisu, Ulytau regions, on the night of February 29, 2024 to March 1, 2024 (Astana time, 12:00 a.m.), to transfer local time back 1 hour Information that the Republic of Kazakhstan is switching to Single Time Zone (UTC+05:00) is sent for accounting in work when interacting with government agencies and organizations of the Republic of Kazakhstan. Please find the attached letter. Sincerely, Mr. Kuanysh Yelikbayev Chairman

2 1

Kazakhstan to shift from UTC+6 to UTC+5
by Dauren Sarsenov Feb. 4, 2024

Feb. 4, 2024

Hello, all. There is an upcoming timezone change I want to inform you about. In Kazakhstan we are moving away from UTC+6 to UTC+5 across all areas of the country. The change is effective at 00:00 1 march 2024. The clock will shift 1 hour back. After the change, only the UTC+5 timezone will remain in the country. I have linked the official statement (no Eng version of the statement though) and some links to news articles: 1) KAZ: https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=kk 2) RUS: https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru 3) KAZ: http://law.gov.kz/client/#!/doc/192700/kaz 4) RUS: http://law.gov.kz/client/#!/doc/192700/rus 5) ENG: https://daryo.uz/en/2024/01/21/kazakhstan-set-to-shift-to-utc5-time-zone-on… 6) ENG: https://qazmonitor.com/news/2430/kazakhstan-to-change-the-clocks-to-single-… The news broke 19th of january, hence informing you at the short notice. Best regards Dauren Sarsenov

5 10

[PROPOSED] Update Israel tz-link
by Paul Eggert Feb. 3, 2024

Feb. 3, 2024

* tz-link.html (National histories of legal time): Update Israel tz history link. (Thanks to Ephraim Silverberg.) --- tz-link.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tz-link.html b/tz-link.html index f11873d9..d41bbce6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -897,9 +897,10 @@ summarizes and cites historical <abbr>DST</abbr> regulations.</dd> href="https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-…">Realisation of Legal Time in Germany</a>.</dd> <dt>Israel</dt> -<dd>The Interior Ministry periodically issues <a -href="ftp://ftp.cs.huji.ac.il/pub/tz/announcements" -hreflang="he">announcements (in Hebrew)</a>.</dd> +<dd><a +href="https://tz.cs.huji.ac.il/">Israel Timezone Files</a> +lists official time-change announcements and laws since 1940, +almost all in Hebrew.</dd> <dt>Malaysia</dt> <dd>See Singapore <a href="#Singapore">below</a>.</dd> <dt>Mexico</dt> -- 2.40.1

1 0

Extending winter time in Palestine
by heba.hamad Feb. 3, 2024

Feb. 3, 2024

3 3

RFC 8536bis
by Michael H Deckers Feb. 2, 2024

Feb. 2, 2024

In 2014b, the new tzdb timezone for Antarctica/Troll required regular switches among three offsets for the foreseeable future. This led to an extension of the TZif format so that the footer could contain two TZ strings (or so I thought); the timezone Antarctica/Troll, hwever, was modified so as to not yet require the new TZif feature. Now it appears that the latest specification "RFC 8536bis" of the TZif format does not allow for two TZ strings in the footer (or at least I did not detect it). Does that mean that the feature "two TZ strings" in a TZif file is further postponed, or is it dropped for good? Michael Deckers.

3 9

[PROPOSED 1/2] Streamline tz-link a bit
by Paul Eggert Feb. 1, 2024

Feb. 1, 2024

* tz-link.html: Defer to the Timezone Boundary Builder web page for a list of libraries that use it, as its list is larger and better-maintained than ours. Mention how old the Manifold map is. Mention WRC 2023 resolution on leap seconds. --- tz-link.html | 36 ++++++++---------------------------- 1 file changed, 8 insertions(+), 28 deletions(-) diff --git a/tz-link.html b/tz-link.html index 78c266ee..9fb57c90 100644 --- a/tz-link.html +++ b/tz-link.html @@ -787,32 +787,9 @@ boundaries of <code><abbr>tzdb</abbr></code> timezones. Its code is freely available under the <abbr>MIT</abbr> license, and its data entries are freely available under the <a href="https://opendatacommons.org/licenses/odbl/">Open Data Commons -Open Database License</a>. The maps' borders appear to be quite accurate.</li> -<li>Programmatic interfaces that map geographical coordinates via tz_world to -<code><abbr>tzdb</abbr></code> timezones include: -<ul> -<li><a href="https://github.com/mj1856/GeoTimeZone">GeoTimeZone</a> is -written in <a -href="https://en.wikipedia.org/wiki/C_Sharp_(programming_language)">C#</a> -and is freely available under the <abbr>MIT</abbr> license.</li> -<li>The <a href="https://github.com/bradfitz/latlong">latlong package</a> -is written in Go and is freely available under the Apache License.</li> -<li><a href="https://github.com/drtimcooper/LatLongToTimezone">LatLongToTimezone</a>, -in both Java and -<a href="https://en.wikipedia.org/wiki/Swift_(programming_language)">Swift</a> -form, is freely available under the MIT license.</li> -<li>For Node.js, -the <a href="https://www.npmjs.com/package/geo-tz">geo-tz module</a> -is freely available under the MIT license, and -the <a href="https://www.npmjs.com/package/tz-lookup">tz-lookup module</a> -is in the public domain.</li> -<li>The <a -href="https://github.com/MrMinimal64/timezonefinder">timezonefinder</a> -library for Python is freely available under the MIT license. -<li>The <a -href="https://github.com/gunyarakun/timezone_finder">timezone_finder</a> -library for Ruby is freely available under the MIT license.</li> -</ul></li> +Open Database License</a>. The borders appear to be quite accurate. +Its main web page lists more than twenty libraries +for looking up a timezone name from a GPS coordinate.</li> <li>Free access via a network API, if you register a key, is provided by the <a href="https://www.geonames.org/export/web-services.html#timezone">GeoNames @@ -833,7 +810,7 @@ Divisions of Countries ("Statoids")</a> lists political subdivision data related to time zones.</li> <li><a href="https://manifold.net/info/freestuff.shtml">Manifold Software – GIS and Database Tools</a> includes a Manifold-format map of -world time zone boundaries distributed under the +world time zone boundaries circa 2007, distributed under the <abbr>GPL</abbr>.</li> <li>A ship within the <a href="https://en.wikipedia.org/wiki/Territorial_waters">territorial @@ -1133,9 +1110,12 @@ might be redefined without Leap Seconds</a> gives pointers on this contentious issue. The General Conference on Weights and Measures -<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">decided in 2022</a> to discontinue the use of leap seconds by 2035, replacing them with an as-yet-undetermined scheme some time after the year 2135. +The World Radiocommunication Conference <a +href="https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf">resolved +in 2023</a> to cooperate with this process. </li> </ul> </section> -- 2.40.1

2 3

[tz-announce] 2024a release of tz code and data available
by Paul Eggert via tz-announce Feb. 1, 2024

Feb. 1, 2024

The 2024a release of the tz code and data is available. This release contains the following changes: Briefly: Kazakhstan unifies on UTC+5 beginning 2024-03-01. Palestine springs forward a week later after Ramadan. zic no longer pretends to support indefinite-past DST. localtime no longer mishandles Ciudad Juárez in 2422. Changes to future timestamps Kazakhstan unifies on UTC+5. This affects Asia/Almaty and Asia/Qostanay which together represent the eastern portion of the country that will transition from UTC+6 on 2024-03-01 at 00:00 to join the western portion. (Thanks to Zhanbolat Raimbekov.) Palestine springs forward a week later than previously predicted in 2024 and 2025. (Thanks to Heba Hamad.) Change spring-forward predictions to the second Saturday after Ramadan, not the first; this also affects other predictions starting in 2039. Changes to past timestamps Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00 not 00:00. (Thanks to Đoàn Trần Công Danh.) From 1947 through 1949, Toronto's transitions occurred at 02:00 not 00:00. (Thanks to Chris Walton.) In 1911 Miquelon adopted standard time on June 15, not May 15. Changes to code The FROM and TO columns of Rule lines can no longer be "minimum" or an abbreviation of "minimum", because TZif files do not support DST rules that extend into the indefinite past - although these rules were supported when TZif files had only 32-bit data, this stopped working when 64-bit TZif files were introduced in 1995. This should not be a problem for realistic data, since DST was first used in the 20th century. As a transition aid, FROM columns like "minimum" are now diagnosed and then treated as if they were the year 1900; this should suffice for TZif files on old systems with only 32-bit time_t, and it is more compatible with bugs in 2023c-and-earlier localtime.c. (Problem reported by Yoshito Umaoka.) localtime and related functions no longer mishandle some timestamps that occur about 400 years after a switch to a time zone with a DST schedule. In 2023d data this problem was visible for some timestamps in November 2422, November 2822, etc. in America/Ciudad_Juarez. (Problem reported by Gilmore Davidson.) strftime %s now uses tm_gmtoff if available. (Problem and draft patch reported by Dag-Erling Smørgrav.) Changes to build procedure The leap-seconds.list file is now copied from the IERS instead of from its downstream counterpart at NIST, as the IERS version is now in the public domain too and tends to be more up-to-date. (Thanks to Martin Burnicki for liaisoning with the IERS.) Changes to documentation The strftime man page documents which struct tm members affect which conversion specs, and that tzset is called. (Problems reported by Robert Elz and Steve Summit.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2024a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2024a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2024a.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 380c07cef01c71c1f93e9709d9f8c79b91cff063 dated 2024-02-01 09:28:56 -0800 and tagged '2024a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 46da8bfa762c7d109db93e5c060789097fc0e1e38bdad5bb8fec886ef47f138bd03b913a743cd5f7e23dc359a72bfd63e7ffc0de199d2b51e6a174361dbdc43c tzcode2024a.tar.gz 1f09f1b2327cc9e1afc7e9045e83ee3377918dafe1bee2f282b6991828d03b3c70a4d3a17f9207dfb1361bb25bc214a8922a756e84fa114e9ba476226db57236 tzdata2024a.tar.gz f1a3b06ea2b28a0bf968b75f3674f3b64d8226338d42e2ed17aea33e34bff0f9a7a22f4116612e6c81b9b7b57deaee6ed01a6881000fa1042a7f4390b55a1856 tzdb-2024a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmW716sACgkQ7ZfpDmKq fjTCyxAAvMohPXC5+oZT9T/X0vhIkK5kJOzDF/eptBVzwxa8WDymp4q7UzGCC2Kg 57dWthckzYqrvcz3QBLagF8bFFVCrQKPiKbMZUYTin+eWrxLUDx1sHOPaxWMPFrY aHjy/HGVMa43P7wp/3iaLLwvuVmcxcWiLy5ebQbXQrFbe09KJDb6mK4ClR+1KdLd aF8BCSU6nI0KQz1bRqmHlm+J7X1ll0E8YymWoK7Ujwht8SYRqpJOqOv2XJ8g0wFO wip6p535KQ3iEIQqc25Swn4v3W26hfa2yZXMh0edgQe1uqqzV3rLi7n8sOrSYjjd uwzyVC6wADGM2PgH4dq6YOeOs9jB+wTm6MEH4/GXP0IpPNPswUnHLK/WJGTHidW4 HJ0hY50S24wMxNYiaiuSbo8Lgefky3GZKZo+umXVKlPjsSrvImaWmFH2gOqvbZIi Ujl/NjDUmH7C4UDGx/ZkLwpOwjcu28hcacLkd6ad3hnFuZhG28yKd9rdQFn6/PTL rX8uAtuJ0GOREWAQWBNKj2dnyOrE45C+EbbuSCobAzvSXMyJ9svb7WuawmhqEjf/ DXY3VJ7pEAViQ/Hqtkxp8R9JfvZ6XCL8EF18eReeJdejjVObNIoUMOyPFX5HXJbs WS8yEl63iDyzzj4Jnvu5dMv8VlWel4CBCCJSkHjtrX9PewqbGq0= =aSZf -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmW716sACgkQ7ZfpDmKq fjTkQQ/6AqS/VNV6+RbbyLbLuOzh4GvYDMq1xTxGnjj7nwr80ob/wwSVmX7Gf5xt gVgagC75EJyskY6dfUPbSHwmOx8Dk2ttQtEprhhzk+1WpUSPZoy/RYMdWN+JzO3s LekrzU86SAh7yP21qSovYRM5rW02Da5RmiLUmknzBpP2cuZsq3qSPYUEMjB3JO39 OzBq0nyLbUR9nqew/f6fcPviyweqTkZdcDsr/+jNUGDI/kezGQ0u3ExlGc0EmGU0 ISAFB7uSDWgoJlwH3ZBtI4lOxiVQRKXafFcdvmLka0hYDGOm6f2zvkhvLEHVN9xK /V680qKy1vIOkyDRp664P9qZ0951+tpb9I47ip7SLqqBoyWhlfb/SJ2eFfb3k+kx fPkCX89QsqkfSPXySJCO13YYEQXpI2VPdWi0JxDI+LD/VEHITiydrYT+afnn0iyZ bM/TKnqaQ4bhAXdLBj3oUSwFQHEgPgeLOrTmWEdN9YmO5Cwbm1gZvOKZ4u2CYW6I ZM+ZwCuNO1hqYRSoeIaN60fUOneXaOcAejlOS/bJr7hNKUtmAjsSS7S7YGeNgQld LXRDRD3vou/qIHlIhmGpTUlOBl5NXVrP42w91nBYEwNyY4lbKLw22GS4FRF1cu9+ wfMfJqY4wwDp/uDMXAfWIXU1AdMg7t1NephMIGg4mivKGYmQmvY= =CvSR -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmW7160ACgkQ7ZfpDmKq fjTlmBAAnPjG9L1PG/4AlnLSdrXhXEVirX6LlmsUjh3DRzXlHjeEHUcD+rEL+wFK cM55uo+yzD7iq1TC1FXxbVKpxFcTxtgNx6Jmz2sHYjymCUmqPFVaj2GtCEwiBaKA CioxHZuQoRaSQnsmGzM/VhC30VMPj1S8SoFNZhbhXkNr0Wxy/f8xxnwcIDRvdzOD 9DvUWqJ5W0jHg/2m4RmbTavsp6tZSdcxoe8R5Ie33tQL7Lwqsze4dkggbzdCFd11 bPhrB9l2mQ6l3KrZ+VQRthL9VJPMrkpgFNK0XiCn+8ctaJS7dFjIspcTtIUbuyiF Z4YMcOUnLdLeL0OwFP1dRNz4kVlLioAO5dfIAHjPdRF0slywcFaw4BWB81Vwwkdy BjkX8nWmFEgYy1DoDYPBf5ju5SNcafPnQ20tO3Cjyzdg57Dc4nN7rd21t6bcPWTw 8FjzOvFoeSjLmzK+4EB5Sx9r0xsP53KSNHYXG272qqkRDtKhi62KNn6ZWR9QMTM7 yIh2OC+yI6Nrp0SAR0CKZQCtM7ghjBQYJeHliW6BzCmAolRaH2Ng5Z+rFDLyxtc2 L+VWkZROyyI5dQrKTpq+pzS6LtidbkM/hyggc0GE2mqGr78f+pEHHXsNkq8xtVNX Z1HLQe0cvORQsi9wH1yNFRlwsflxfN1VHhNhNXvYdtvJLfbwr7M= =Yw45 -----END PGP SIGNATURE-----

1 0

Kazakhstan timezone switch from 01.03.2024
by Yegor Fyodorov Feb. 1, 2024

Feb. 1, 2024

Dear sirs, I want to notify you that Kazakstan's government made a decision to switch timezone for the whole country to one timezone only: UTC+5. Right now there are 2 timezones: UTC+5 and UTC+6. The switch is going to happen on 1st march 2024. As far as I can see this change is not implemented in 2023d version of timezone database. Is it possible to add this change? Kazakstan is a big country, so a lot of users will be affected. And there is only 1 month left to implement this change. Some links for the news. Unfortunatelly official news are only in Russian / Kazakh language, but you can use google translate. Kazakhstan will switch to a single time zone, UTC+05:00, on March 1, 2024: https://en.wikipedia.org/wiki/Time_in_Kazakhstan According to Ministry of Trade and Integration of the Republic of Kazakhstan website: https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru -- Best regards, Yegor Fyodorov

2 1