From eggert at cs.ucla.edu Thu Feb 1 08:09:12 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 1 Feb 2024 00:09:12 -0800 Subject: [tz] [PROPOSED 1/2] Streamline tz-link a bit Message-ID: <20240201080913.124917-1-eggert@cs.ucla.edu> * 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 tzdb timezones. Its code is freely available under the MIT license, and its data entries are freely available under the Open Data Commons -Open Database License. The maps' borders appear to be quite accurate. -
  • Programmatic interfaces that map geographical coordinates via tz_world to -tzdb timezones include: -
    • +Open Database License. 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.
  • Free access via a network API, if you register a key, is provided by the GeoNames @@ -833,7 +810,7 @@ Divisions of Countries ("Statoids") lists political subdivision data related to time zones.
  • Manifold Software – GIS and Database Tools includes a Manifold-format map of -world time zone boundaries distributed under the +world time zone boundaries circa 2007, distributed under the GPL.
  • A ship within the territorial @@ -1133,9 +1110,12 @@ might be redefined without Leap Seconds gives pointers on this contentious issue. The General Conference on Weights and Measures -voted in 2022 +decided in 2022 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 resolved +in 2023 to cooperate with this process.
    • -- 2.40.1 From eggert at cs.ucla.edu Thu Feb 1 08:09:13 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 1 Feb 2024 00:09:13 -0800 Subject: [tz] [PROPOSED 2/2] Update a few stale links * theory.html, tz-art.html: Update stale links and normalize some punctuation and white space. In-Reply-To: <20240201080913.124917-1-eggert@cs.ucla.edu> References: <20240201080913.124917-1-eggert@cs.ucla.edu> Message-ID: <20240201080913.124917-2-eggert@cs.ucla.edu> --- theory.html | 2 +- tz-art.html | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/theory.html b/theory.html index 318b6c25..516d2a52 100644 --- a/theory.html +++ b/theory.html @@ -770,7 +770,7 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes calendar with 24-hour days. These divergences range from relatively minor, such as Japanese bars giving times like "24:30" for the wee hours of the morning, to more-significant differences such as the + href="https://theworld.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-better-double-check-time">the east African practice of starting the day at dawn, renumbering the Western 06:00 to be 12:00. These practices are largely outside the scope of the tz code and data, which diff --git a/tz-art.html b/tz-art.html index 2131cfd4..3ee1eb24 100644 --- a/tz-art.html +++ b/tz-art.html @@ -210,7 +210,7 @@ Umberto Eco, Island of the Day Before (L'isola del giorno prima), 1994. "...the story of a 17th century Italian nobleman trapped near an island -on the International Date Line. Time and time zones play an integral +on the International Date Line. Time and time zones play an integral part in the novel." (Paul Eggert, 2006-04-22)
  • @@ -293,7 +293,7 @@ ADO ★★⯪,
  • Milt Hinton, -Old +Old Man Time (1990). Chiaroscuro CR(D) 310, 149:38 (two CDs). Milt Hinton, bass; @@ -556,10 +556,10 @@ entitled "The Kid," originally aired 1997-11-04)
  • "I put myself and my staff through this crazy, huge ordeal, all because -I refused to go on at midnight, okay? And so I work, you know, and -then I get this job at eleven, supposed to be a big deal. Then +I refused to go on at midnight, okay? And so I work, you know, and +then I get this job at eleven, supposed to be a big deal. Then yesterday daylight [saving] time ended. Right now it's basically -midnight." (Conan O'Brien on the 2010-11-08 premiere of Conan.) +midnight." (Conan O'Brien on the 2010-11-08 premiere of Conan)
  • "The best method, I told folks, was to hang a large clock high on a @@ -567,7 +567,7 @@ barn wall where all the cows could see it. If you have Holsteins, you will need to use an analog clock." (Jerry Nelson, How to adjust dairy cows to daylight saving time", Successful Farming, -2017-10-09.) +2017-10-09)
  • "And now, driving to California, I find that I must enter a password -- 2.40.1 From brian.inglis at systematicsw.ab.ca Thu Feb 1 16:02:26 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Thu, 1 Feb 2024 09:02:26 -0700 Subject: [tz] [PROPOSED 1/2] Streamline tz-link a bit In-Reply-To: <20240201080913.124917-1-eggert@cs.ucla.edu> References: <20240201080913.124917-1-eggert@cs.ucla.edu> Message-ID: <977cd6fe-f004-4e56-a4b2-bf8d79dd3e1c@systematicsw.ab.ca> On 2024-02-01 01:09, Paul Eggert via tz wrote: ... > The General Conference on Weights and Measures > -voted in 2022 > +decided in 2022 > to discontinue the use of leap seconds by 2035, replacing them with an > as-yet-undetermined scheme some time after the year 2135. I would keep the official bureaucratic weasel words: "requests...consult...propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century" which hopefully might be agreed by 2035, unless anyone with a big stick, or who can raise a big political stink, disrupt it, like conservative, including religious, groups, who may feel their beliefs, standards, influence, or power are being threatened: just like the last 20-50 years! > +The World Radiocommunication Conference +href="https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf">resolved > +in 2023 to cooperate with this process. It seems that telecommunications organizations have little to no role to play in disseminating any modern time or frequency standards, except regulators who need to keep GNSS bands free of all interference terrestrial or extra-terrestrial? -- 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 From michael.h.deckers at googlemail.com Thu Feb 1 16:41:17 2024 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Thu, 1 Feb 2024 16:41:17 +0000 Subject: [tz] RFC 8536bis In-Reply-To: References: <46982945-43e9-4148-874f-8fdbe3b40ce8@googlemail.com> <9d2da609-8358-4865-9339-95c9eba1dd9c@googlemail.com> Message-ID: <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> ?? On 2024-01-31 21:23, Paul Eggert wrote: > That merely causes zic to accept .zi input containing four transitions > per year for the foreseeable future. Input like this, for example: > > ? Rule Troll 2005 max - Mar?????? 1 1:00u 1:00 +01 > ? Rule Troll 2005 max - Mar lastSun 1:00u 2:00 +02 > ? Rule Troll 2005 max - Oct lastSun 1:00u 1:00 +01 > ? Rule Troll 2004 max - Nov?????? 7 1:00u 0:00 +00 > ? Zone Antarctica/Troll 0??? -???? -00 2005 Feb 12 > ??????????????????????? 0:00 Troll %s > > (This isn't in tzdata, but it could be once we can assume tzcode 2014b > or later.) > > When zic sees input like this, it generates a big TZif file with > explicit transitions out to the year 2407 (2005 + 402 years). The big > TZif file does not have a TZ string, because no TZ string can > represent all these transitions. ?? Maybe I did not get it. Are you saying that zic (after 2014b) treats the input ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT????? SAVE??? LETTER/S ??????? Rule?? Troll?? 2005??? max???? -?????? Mar????? 1 1:00u?? 1:00??? +01 ??????? Rule?? Troll?? 2005??? max???? -?????? Mar???? lastSun 1:00u?? 2:00??? +02 ??????? Rule?? Troll?? 2005??? max???? -?????? Oct???? lastSun 1:00u?? 1:00??? +01 ??????? Rule?? Troll?? 2004??? max???? -?????? Nov????? 7 1:00u?? 0:00??? +00 ?? as if it were ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT????? SAVE??? LETTER/S ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar????? 1 1:00u?? 1:00??? +01 ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar???? lastSun 1:00u?? 2:00??? +02 ??????? Rule?? Troll?? 2005??? 2407??? -?????? Oct???? lastSun 1:00u?? 1:00??? +01 ??????? Rule?? Troll?? 2004??? 2407??? -?????? Nov????? 7 1:00u?? 0:00??? +00 ?? If so -- why don't we just specify Rule Troll in the latter form so that ?? it correctly describes what is produced by zic? No change in zic would ?? have been required. ?? Or does zic treat it as if it were ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT????? SAVE??? LETTER/S ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar????? 1 1:00u?? 1:00??? +01 ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar???? lastSun 1:00u?? 2:00??? +02 ??????? Rule?? Troll?? 2005??? 2407??? -?????? Oct???? lastSun 1:00u?? 1:00??? +01 ??????? Rule?? Troll?? 2004??? 2406??? -?????? Nov????? 7 1:00u?? 0:00??? +00 ?? Where is this behavior of zic documented so that one can find out? ?? More basically, I believe that a compiler that tacitly changes the ?? source code in this manner if it cannot correctly compile the ?? original source is detrimental to the production of reliable software. ?? Michael Deckers. From brian.inglis at systematicsw.ab.ca Thu Feb 1 17:35:26 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Thu, 1 Feb 2024 10:35:26 -0700 Subject: [tz] RFC 8536bis In-Reply-To: <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> References: <46982945-43e9-4148-874f-8fdbe3b40ce8@googlemail.com> <9d2da609-8358-4865-9339-95c9eba1dd9c@googlemail.com> <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> Message-ID: <9497e546-bd10-43cf-9620-4995b31d3874@systematicsw.ab.ca> On 2024-02-01 09:41, Michael H Deckers via tz wrote: > ?? On 2024-01-31 21:23, Paul Eggert wrote: >> That merely causes zic to accept .zi input containing four transitions per >> year for the foreseeable future. Input like this, for example: >> >> ? Rule Troll 2005 max - Mar?????? 1 1:00u 1:00 +01 >> ? Rule Troll 2005 max - Mar lastSun 1:00u 2:00 +02 >> ? Rule Troll 2005 max - Oct lastSun 1:00u 1:00 +01 >> ? Rule Troll 2004 max - Nov?????? 7 1:00u 0:00 +00 >> ? Zone Antarctica/Troll 0??? -???? -00 2005 Feb 12 >> ??????????????????????? 0:00 Troll %s >> >> (This isn't in tzdata, but it could be once we can assume tzcode 2014b or later.) >> >> When zic sees input like this, it generates a big TZif file with explicit >> transitions out to the year 2407 (2005 + 402 years). The big TZif file does >> not have a TZ string, because no TZ string can represent all these transitions. > > > > ?? Maybe I did not get it. Are you saying that zic (after 2014b) treats the input > > ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT SAVE??? LETTER/S > ??????? Rule?? Troll?? 2005??? max???? -?????? Mar????? 1 1:00u 1:00??? +01 > ??????? Rule?? Troll?? 2005??? max???? -?????? Mar???? lastSun 1:00u 2:00??? +02 > ??????? Rule?? Troll?? 2005??? max???? -?????? Oct???? lastSun 1:00u 1:00??? +01 > ??????? Rule?? Troll?? 2004??? max???? -?????? Nov????? 7 1:00u 0:00??? +00 > > ?? as if it were > > ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT SAVE??? LETTER/S > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar????? 1 1:00u 1:00??? +01 > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar???? lastSun 1:00u 2:00??? +02 > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Oct???? lastSun 1:00u 1:00??? +01 > ??????? Rule?? Troll?? 2004??? 2407??? -?????? Nov????? 7 1:00u 0:00??? +00 > > ?? If so -- why don't we just specify Rule Troll in the latter form so that > ?? it correctly describes what is produced by zic? No change in zic would > ?? have been required. > > ?? Or does zic treat it as if it were > > ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT SAVE??? LETTER/S > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar????? 1 1:00u 1:00??? +01 > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar???? lastSun 1:00u 2:00??? +02 > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Oct???? lastSun 1:00u 1:00??? +01 > ??????? Rule?? Troll?? 2004??? 2406??? -?????? Nov????? 7 1:00u 0:00??? +00 > > ?? Where is this behavior of zic documented so that one can find out? > > ?? More basically, I believe that a compiler that tacitly changes the > ?? source code in this manner if it cannot correctly compile the > ?? original source is detrimental to the production of reliable software. Compilers can not change source code, they transform it into what they consider a useful form for the target; sometimes default limits are imposed, as arbitrary verges towards pointless; often these may be changed, depending on target capabilities. If the target limit is insufficient, you may be able to extend the output to 4kyr, 9kyr, etc. using range arguments. It may be a limitation of the supported output formats and readers using them, so readers may be unable to process extended ranges. I suspect the developer thought that as the Gregorian calendar has been unchanged for 400yr, projecting changes another 400yr should be adequate, as the calendar or rules are likely to be changed by then. For the most frequent use of these features, Ramadan rules, unless the dates are predicted using astronomical software for lunar visibility at the specific locations involved, the dates are only approximate, and also depend on the month change visibility rules for each location, which may be eyeball dependent. Suggest patches to improve the behaviour or documentation. -- 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 From tim at timtimeonline.com Thu Feb 1 17:58:23 2024 From: tim at timtimeonline.com (Tim Parenti) Date: Thu, 1 Feb 2024 12:58:23 -0500 Subject: [tz] Kazakhstan timezone switch from 01.03.2024 In-Reply-To: <1482647485.20240131171330@web-design.lv> References: <1482647485.20240131171330@web-design.lv> Message-ID: On Wed, 31 Jan 2024 at 14:37, Yegor Fyodorov via tz wrote: > Is it possible to add this change? > This change was made in our development repository on 19 January, see: https://github.com/eggert/tz/commit/95a16c87f21c4643055482429dad921357a630c9 A new release, 2024a, has been prepared which should appear shortly at: https://www.iana.org/time-zones -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggert at cs.ucla.edu Thu Feb 1 18:36:23 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 1 Feb 2024 10:36:23 -0800 Subject: [tz] RFC 8536bis In-Reply-To: <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> References: <46982945-43e9-4148-874f-8fdbe3b40ce8@googlemail.com> <9d2da609-8358-4865-9339-95c9eba1dd9c@googlemail.com> <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> Message-ID: On 2024-02-01 08:41, Michael H Deckers wrote: > Are you saying that zic (after 2014b) treats > the input > > ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT SAVE > LETTER/S > ??????? Rule?? Troll?? 2005??? max???? -?????? Mar????? 1 1:00u 1:00 > +01 > ??????? Rule?? Troll?? 2005??? max???? -?????? Mar???? lastSun 1:00u > 2:00??? +02 > ??????? Rule?? Troll?? 2005??? max???? -?????? Oct???? lastSun 1:00u > 1:00??? +01 > ??????? Rule?? Troll?? 2004??? max???? -?????? Nov????? 7 1:00u 0:00 > +00 > > ?? as if it were > > ??????? # Rule NAME??? FROM??? TO????? -?????? IN????? ON AT SAVE > LETTER/S > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar????? 1 1:00u 1:00 > +01 > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Mar???? lastSun 1:00u > 2:00??? +02 > ??????? Rule?? Troll?? 2005??? 2407??? -?????? Oct???? lastSun 1:00u > 1:00??? +01 > ??????? Rule?? Troll?? 2004??? 2407??? -?????? Nov????? 7 1:00u 0:00 > +00 Yes, that's it. > ?? If so -- why don't we just specify Rule Troll in the latter form so > that > ?? it correctly describes what is produced by zic? As I recall, the goal was to have the data be as close as possible to what we want to predict, and to have zic implement that as best it can, which is not perfectly due to the limitations of the TZif format. It's similar to how zic implements this: Zone Europe/Amsterdam 0:19:32.13 - LMT It drops the ".13". If you use zic -v it issues a warning. > ?? Where is this behavior of zic documented so that one can find out? In zic.8; look for -v. > ?? a compiler that tacitly changes the > ?? source code in this manner if it cannot correctly compile the > ?? original source is detrimental to the production of reliable software. Try -v and see what you think. From tz-announce at iana.org Thu Feb 1 18:53:31 2024 From: tz-announce at iana.org (Paul Eggert via tz-announce) Date: Thu, 1 Feb 2024 10:53:31 -0800 Subject: [tz] [tz-announce] 2024a release of tz code and data available Message-ID: 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 . 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----- From eggert at cs.ucla.edu Thu Feb 1 19:32:19 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 1 Feb 2024 11:32:19 -0800 Subject: [tz] [PROPOSED 1/2] Streamline tz-link a bit In-Reply-To: <977cd6fe-f004-4e56-a4b2-bf8d79dd3e1c@systematicsw.ab.ca> References: <20240201080913.124917-1-eggert@cs.ucla.edu> <977cd6fe-f004-4e56-a4b2-bf8d79dd3e1c@systematicsw.ab.ca> Message-ID: <0cf229b0-753a-4337-bf42-9c657ccd9ab5@cs.ucla.edu> On 2024-02-01 08:02, brian.inglis--- via tz wrote: > I would keep the official bureaucratic weasel words: Ironically, I changed tz-link's "voted" to "decided" to use the exact word "decided" that the GCPM used.... > "requests...consult...propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century" I installed the attached proposed patch to try to do that. Unfortunately is written so bureaucratically that it's hard to understand what it means. At its core I think it means "We decide to discontinue leap seconds by 2035" and "maybe our descendants will do something different". I've tried to write this meaning plainly rather than to slip into too much bureaucratese. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Extrapolate-less-from-the-2022-CGPM-resolution.patch Type: text/x-patch Size: 1953 bytes Desc: not available URL: From michael.h.deckers at googlemail.com Fri Feb 2 16:10:16 2024 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Fri, 2 Feb 2024 16:10:16 +0000 Subject: [tz] RFC 8536bis In-Reply-To: <9497e546-bd10-43cf-9620-4995b31d3874@systematicsw.ab.ca> References: <46982945-43e9-4148-874f-8fdbe3b40ce8@googlemail.com> <9d2da609-8358-4865-9339-95c9eba1dd9c@googlemail.com> <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> <9497e546-bd10-43cf-9620-4995b31d3874@systematicsw.ab.ca> Message-ID: <5fe0d969-43e1-49ba-ba03-05d1c252f2a8@googlemail.com> ?? On 2024-02-01 17:35, brian.inglis--- via tz wrote: > I suspect the developer thought that as the Gregorian calendar has > been unchanged for 400yr, projecting changes another 400yr should be > adequate, as the calendar or rules are likely to be changed by then. > ?? I rather think that the 400 years are enough to derive the ?? transitions throughout the indefinite future by a simple lookup ?? in TZif data: for years 2408..2807, use the transitions of ?? years 2008..2407, ie, 400 years earlier, etc. If localtime() etc ?? would do that, then they would implement the Rules as originally ?? written. > Suggest patches to improve the behaviour or documentation. ?? I actually tried to do that: explicitly write the Rules ?? with 2407 instead of max, so as to make it explicit that ?? the Rules only apply for 402 years. ?? Michael Deckers. From michael.h.deckers at googlemail.com Fri Feb 2 16:10:55 2024 From: michael.h.deckers at googlemail.com (Michael H Deckers) Date: Fri, 2 Feb 2024 16:10:55 +0000 Subject: [tz] RFC 8536bis In-Reply-To: References: <46982945-43e9-4148-874f-8fdbe3b40ce8@googlemail.com> <9d2da609-8358-4865-9339-95c9eba1dd9c@googlemail.com> <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> Message-ID: <698feb96-6319-42cd-8160-08019075ba5f@googlemail.com> ?? On 2024-02-01 18:36, Paul Eggert wrote: > As I recall, the goal was to have the data be as close as possible to > what we want to predict, and to have zic implement that as best it > can, which is not perfectly due to the limitations of the TZif format. ?? Agreed. And currently, what we want to predict for the ?? future of Rule Troll is commented out, in favor of a ?? description of what currently is done. I do not see a ?? reason why this same scheme could not be applied with ?? 'max' (our prediction) replaced by '2407' (as best as ?? zic can do with the code of 2014b). > > > It's similar to how zic implements this: > > Zone Europe/Amsterdam??? 0:19:32.13 -??? LMT > > It drops the ".13". If you use zic -v it issues a warning. > ?? There is a decisive difference: zic(8) explicitly ?? says that ????? ..zic rounds times to the nearest integer second ?????? (breaking ties to the even integer),... ?? while I have not found an indication in zic(8) when ?? the "400 year hack" applies. > Try -v and see what you think. ?? I am sorry but I would not use a C compiler that ?? successfully compiles a translation unit containing ??????????? int A[ SIZE_MAX ] ; ?? together with a warning to the effect that array A ?? has been shortened to 402 elements. Apparently I am ?? too picky. ?? Michael Deckers. From tim at timtimeonline.com Fri Feb 2 19:17:27 2024 From: tim at timtimeonline.com (Tim Parenti) Date: Fri, 2 Feb 2024 14:17:27 -0500 Subject: [tz] Kazakhstan to shift from UTC+6 to UTC+5 In-Reply-To: References: <373277D7-3F51-4623-A2C5-59BA112C5C74@gmail.com> <2ecc0e8b99584d36b6e54f39379111ea@erg.kz> Message-ID: On Fri, 2 Feb 2024 at 03:19, Andrey.Kazakevich at erg.kz < Andrey.Kazakevich at erg.kz> wrote: > Does it mean that we don?t need to do TZ changes on our local corporate > servers if they are using Asia/Almaty TZ at this time? > I'm not sure I'm understanding the question. At a minimum, your servers will need to take whatever time zone definition updates are available to them, and you'll want to ensure that those using tzdb have got at least version 2024a. It may take a while longer until those updates are ready for any given system, though. A tz release like yesterday's is just an initial step in a distribution process that involves various vendors of operating systems, programming libraries, and telecommunications infrastructure, all repackaging our release for use within their own respective ecosystems. Depending on what your servers are doing, you may need updates from any or all of these sources which are all downstream of us. This is why we typically recommend several months' notice in advance of time zone changes whenever possible. And as a reminder, Microsoft uses a completely separate process from us for disseminating time zone updates to Windows devices. So if your servers are Windows servers, we can't really help other than to point again to "(UTC+05:00) Ashgabat, Tashkent" as a potential workaround. -- Tim Parenti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrey.Kazakevich at erg.kz Fri Feb 2 08:18:23 2024 From: Andrey.Kazakevich at erg.kz (Andrey.Kazakevich at erg.kz) Date: Fri, 2 Feb 2024 08:18:23 +0000 Subject: [tz] Kazakhstan to shift from UTC+6 to UTC+5 In-Reply-To: References: <373277D7-3F51-4623-A2C5-59BA112C5C74@gmail.com> <2ecc0e8b99584d36b6e54f39379111ea@erg.kz> Message-ID: Hi, guys! As we can see an update in TZ DB was released yesterday (2024a (Released 2024-02-01)). And I see that our timezone (Asia/Almaty) figured with future change there. Does it mean that we don?t need to do TZ changes on our local corporate servers if they are using Asia/Almaty TZ at this time? Time will swap automatically or how it will be? ?/? Andrey Kazakevich From: Tim Parenti Sent: Thursday, January 25, 2024 9:39 PM To: Andrey Kazakevich Cc: tz at iana.org; Rustam Sirotkin Subject: Re: [tz] Kazakhstan to shift from UTC+6 to UTC+5 ????????: ?????? ?????? ?????????? ????? ERG. ?? ?????????? ?????? ? ????????, ???? ?? ?? ?????? ??????????? ? ?? ??????? ? ???????????? ???????????. On Wed, 24 Jan 2024 at 22:52, Andrey.Kazakevich at erg.kz > wrote: Sorry, guys, another question ? most of devices in our corporate environment are using (Astana +06:00) timezone in Microsoft Windows OS (Win10/11, Win Server 2019/2022). Have you some information how are they changing their list of timezones? What is process in their global list? We are not involved with Microsoft's process for time zone data, no. Once they do announce a change, it will likely end up on their blog where they document their DST and time zone updates at: https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/bg-p/DSTBlog Found some article (https://techcommunity.microsoft.com/t5/windows-it-pro-blog/how-windows-manages-time-zone-changes/ba-p/3852632) but they declare 8 weeks change duration there? Yes, it's a complex process to propagate time zone updates to devices around the world. It's why we recommend at least a year's notice ahead of changes whenever possible. Because this change is so soon, it is quite likely that some devices won't receive updated time zone definitions in time. As a workaround, users may need to consider temporarily using Asia/Aqtobe or Asia/Tashkent on devices that use tzdb, although these will mishandle timestamps before the change. On Windows, a similar approach may look like using "(UTC+05:00) Ashgabat, Tashkent", as I believe that's already the correct choice in western portions of Kazakhstan. -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggert at cs.ucla.edu Sat Feb 3 01:56:47 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 2 Feb 2024 17:56:47 -0800 Subject: [tz] Kazakhstan to shift from UTC+6 to UTC+5 In-Reply-To: References: <373277D7-3F51-4623-A2C5-59BA112C5C74@gmail.com> <2ecc0e8b99584d36b6e54f39379111ea@erg.kz> Message-ID: <1a5c4146-f928-445b-9631-8e8542a2a917@cs.ucla.edu> On 2/2/24 11:17, Tim Parenti via tz wrote: > Depending on what your servers are doing, you may need updates from any or > all of these sources which are all downstream of us. Also, after installing a TZDB update on a machine you may need to restart subsystems, or even reboot the machine, to propagate the update to running processes. Whether you need to do this depends on what software you're running. From eggert at cs.ucla.edu Sat Feb 3 02:05:52 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 2 Feb 2024 18:05:52 -0800 Subject: [tz] RFC 8536bis In-Reply-To: <698feb96-6319-42cd-8160-08019075ba5f@googlemail.com> References: <46982945-43e9-4148-874f-8fdbe3b40ce8@googlemail.com> <9d2da609-8358-4865-9339-95c9eba1dd9c@googlemail.com> <217d2fe8-1d45-4f7f-9d8b-4750dea4c646@googlemail.com> <698feb96-6319-42cd-8160-08019075ba5f@googlemail.com> Message-ID: <2e1dd3e9-527f-4d51-ace0-556ac2f18aca@cs.ucla.edu> On 2/2/24 08:10, Michael H Deckers wrote: > There is a decisive difference: zic(8) explicitly says that > > ..zic rounds times to the nearest integer second (breaking ties to > the even integer),... > > while I have not found an indication in zic(8) when the "400 year > hack" applies. I was thinking of this part of zic(8): -v Be more verbose, and complain about the following situations: ... The output file does not contain all the information about the long-term future of a timezone, because the future cannot be summarized as an extended POSIX TZ string. > I would not use a C compiler that successfully > compiles a translation unit containing > > int A[ SIZE_MAX ] ; They're not quite the same situation. Still, that's a valid point. Perhaps zic should not try to compile unrepresentable Zone entries like these (i.e., go back to something like its behavior in tzcode 2014a and earlier), and we should remove any suggestion in the 'antarctica' comments that zic can compile the commented-out lines. From brian.inglis at systematicsw.ab.ca Sat Feb 3 08:54:36 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Sat, 3 Feb 2024 01:54:36 -0700 Subject: [tz] Kazakhstan to shift from UTC+6 to UTC+5 In-Reply-To: References: <373277D7-3F51-4623-A2C5-59BA112C5C74@gmail.com> <2ecc0e8b99584d36b6e54f39379111ea@erg.kz> Message-ID: On 2024-02-02 12:17, Tim Parenti via tz wrote: > On Fri, 2 Feb 2024 at 03:19, Andrey Kazakevich wrote: >> Does it mean that we don?t need to do TZ changes on our local corporate >> servers if they are using Asia/Almaty TZ at this time? > I'm not sure I'm understanding the question.? At a minimum, your servers will > need to take whatever time zone definition updates are available to them, and > you'll want to ensure that those using tzdb have got at least version?2024a. > > It may take a while longer until those updates are ready for any given system, > though.? A tz release like yesterday's is just an initial?step in a distribution > process that involves various vendors of operating systems, programming > libraries, and telecommunications infrastructure, all repackaging our release > for use within their own respective ecosystems.? Depending on what your servers > are doing, you may need updates from?any or all of these sources which are all > downstream of us.? This is why we typically recommend several months' notice in > advance of time zone changes whenever possible. > > And as a reminder, Microsoft uses a completely separate process from us for > disseminating time zone updates to Windows devices.? So if your servers are > Windows servers, we can't really help other than to point again to "(UTC+05:00) > Ashgabat, Tashkent" as a potential workaround. You can see if any MS products support any time zone update by checking: https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/bg-p/DSTBlog and apply any available updates to the affected products, otherwise you will have to use the suggested workaround above to switch to that or an equivalent time zone you may already use, on February 29 24:00/March 1 00:00. Different products may require different time zone selections to make the desired change. For example, each OS, MS Windows, Outlook, Exchange, Azure, WSL, Java, database software, may each require their own updates and time zone setting. -- 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 From brian.inglis at systematicsw.ab.ca Sat Feb 3 21:06:15 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Sat, 3 Feb 2024 14:06:15 -0700 Subject: [tz] Extending winter time in Palestine In-Reply-To: <18776cb1-ba54-4506-b142-26660ff32fb9@cs.ucla.edu> References: <20240125133238.40PDWcAT005399@mtit.gov.ps> <18776cb1-ba54-4506-b142-26660ff32fb9@cs.ucla.edu> Message-ID: On 2024-01-25 13:46, Paul Eggert via tz wrote: > Thanks for letting us know. This means TZDB will need to change for the > spring-forward transitions in 2024 and 2025. Given that Ramadan is a lunar month, occurring in any season and spring only 25% of the time, and that Shawwal is the next month, a better phrase for the resumption of an alternate time might be "Shawwal forward", which is somewhat homonymic with "shuffle" in English. There should be some better sources available of accurate astronomical moon sighting calculations which can provide better predictions of global high probability dates and dates for specific locations years into the future, similar to those used in Europe. -- 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 From eggert at cs.ucla.edu Sun Feb 4 01:29:08 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sat, 3 Feb 2024 17:29:08 -0800 Subject: [tz] Extending winter time in Palestine In-Reply-To: References: <20240125133238.40PDWcAT005399@mtit.gov.ps> <18776cb1-ba54-4506-b142-26660ff32fb9@cs.ucla.edu> Message-ID: On 2024-02-03 13:06, brian.inglis--- via tz wrote: > There should be some better sources available of accurate astronomical > moon sighting calculations The timestamps TZDB documents are civil timestamps, not religious ones. This is why TZDB cites the Palestinian Cabinet's predictions, not the astronomical observations that are the basis of the Islamic calendar. Although I don't know, I guess that start-of-Ramadan crescent moon sightings in Palestine are evaluated by an investigation committee of the Palestinian Fatwa House . If so, surely the Cabinet would defer to the Fatwa House if the Cabinet's conservative predictions of a period of time around Ramadan turn out to be not conservative enough. However, if this (dare I say it?) astronomically improbable event occurs, that won't change the start and end of Ramadan - all it would mean is that legal clock changes wouldn't match Ramadan that year, due to the Cabinet's mistake. At most the Cabinet would make some last-second correction (perhaps even an ex-post-facto correction!) and tzdata could continue to cite just the Cabinet. This is because TZDB's goal is to document what human clocks say, not what the earth and moon are doing. From eggert at cs.ucla.edu Sun Feb 4 07:18:28 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sat, 3 Feb 2024 23:18:28 -0800 Subject: [tz] [PROPOSED] Update Israel tz-link Message-ID: <20240204071828.665622-1-eggert@cs.ucla.edu> * 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 DST regulations. href="https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-legal-time-in-germany.html">Realisation of Legal Time in Germany.
    Israel
    -
    The Interior Ministry periodically issues announcements (in Hebrew).
    +
    Israel Timezone Files +lists official time-change announcements and laws since 1940, +almost all in Hebrew.
    Malaysia
    See Singapore below.
    Mexico
    -- 2.40.1 From Andrey.Kazakevich at erg.kz Mon Feb 5 03:29:24 2024 From: Andrey.Kazakevich at erg.kz (Andrey.Kazakevich at erg.kz) Date: Mon, 5 Feb 2024 03:29:24 +0000 Subject: [tz] Kazakhstan to shift from UTC+6 to UTC+5 In-Reply-To: References: <373277D7-3F51-4623-A2C5-59BA112C5C74@gmail.com> <2ecc0e8b99584d36b6e54f39379111ea@erg.kz> Message-ID: <4cf97684fdf0476dbe8f289da81e46d1@erg.kz> Hi, thank you very much for such detailed info! Understood all of that. ?/? Andrey Kazakevich From: Tim Parenti Sent: Saturday, February 3, 2024 1:17 AM To: Andrey Kazakevich Cc: tz at iana.org; Rustam Sirotkin Subject: Re: [tz] Kazakhstan to shift from UTC+6 to UTC+5 ????????: ?????? ?????? ?????????? ????? ERG. ?? ?????????? ?????? ? ????????, ???? ?? ?? ?????? ??????????? ? ?? ??????? ? ???????????? ???????????. On Fri, 2 Feb 2024 at 03:19, Andrey.Kazakevich at erg.kz > wrote: Does it mean that we don?t need to do TZ changes on our local corporate servers if they are using Asia/Almaty TZ at this time? I'm not sure I'm understanding the question. At a minimum, your servers will need to take whatever time zone definition updates are available to them, and you'll want to ensure that those using tzdb have got at least version 2024a. It may take a while longer until those updates are ready for any given system, though. A tz release like yesterday's is just an initial step in a distribution process that involves various vendors of operating systems, programming libraries, and telecommunications infrastructure, all repackaging our release for use within their own respective ecosystems. Depending on what your servers are doing, you may need updates from any or all of these sources which are all downstream of us. This is why we typically recommend several months' notice in advance of time zone changes whenever possible. And as a reminder, Microsoft uses a completely separate process from us for disseminating time zone updates to Windows devices. So if your servers are Windows servers, we can't really help other than to point again to "(UTC+05:00) Ashgabat, Tashkent" as a potential workaround. -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: From yelikbayev at mti.gov.kz Mon Feb 5 05:28:00 2024 From: yelikbayev at mti.gov.kz (=?utf-8?q?=D0=95=D0=9B=D0=98=D0=9A=D0=91=D0=90=D0=95=D0=92_=D0=9A=D0=A3=D0=90=D0=9D=D0=AB=D0=A8_=D0=9D=D0=A3=D0=A0=D0=9B=D0=90=D0=9D=D0=9E=D0=92=D0=98=D0=A7?=) Date: Mon, 05 Feb 2024 11:28:00 +0600 Subject: [tz] the Republic of Kazakhstan Message-ID: <2a0a-65c07200-27-172fe220@4773163> 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??????????? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.davies at iana.org Mon Feb 5 23:39:03 2024 From: kim.davies at iana.org (Kim Davies) Date: Mon, 5 Feb 2024 23:39:03 +0000 Subject: [tz] the Republic of Kazakhstan In-Reply-To: <2a0a-65c07200-27-172fe220@4773163> References: <2a0a-65c07200-27-172fe220@4773163> Message-ID: Dear Mr Yelikbayev, Thank you for your email to the Time Zone discussion list, and ICANN today also received a letter with the same content. The substance of the change to Kazakhstan time zone policy was implemented in the most recent update to the Time Zone Database, published on 1 February 2024. Please note that dissemination of updated time zone data typically takes many months, and therefore you should not expect devices to comprehensively adopt the time zone change on 1 March due to the short lead time. We recommend such changes should be made with at least one year of prior notice to allow time to not just update the IANA time zone database, but for software vendors to consequently propagate those changes through software updates and the like. Kindest regards, Kim Davies Internet Assigned Numbers Authority From: "tz-bounces at iana.org" on behalf of ???????? ?????? ?????????? via tz Reply-To: ???????? ?????? ?????????? Date: Monday, February 5, 2024 at 2:04?PM To: "tz at iana.org" Subject: [tz] the Republic of Kazakhstan 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 [zan.gov.kz]), 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From b at torresjrjr.com Tue Feb 6 22:25:21 2024 From: b at torresjrjr.com (Byron Torres) Date: Tue, 06 Feb 2024 22:25:21 +0000 Subject: [tz] leap-seconds.list format Message-ID: 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/d0c057dbbb0f1ee9179769e187c0fbd3b00327d4/item/time/chrono/leapsec.ha#L72 [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 From eggert at cs.ucla.edu Wed Feb 7 01:48:14 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Tue, 6 Feb 2024 17:48:14 -0800 Subject: [tz] leap-seconds.list format In-Reply-To: References: Message-ID: <7e85a50c-8447-48ad-bd4f-4133036bfca6@cs.ucla.edu> On 2/6/24 14:25, Byron Torres via tz wrote: > * What was the motivation for the changes in IERS'es leap-seconds.list > file? Is there a record of discussion regarding this? I don't know the motivation for format changes, or any record of discussion. > * What was the motivation specifically for the spaces-to-tab change? > Did another commonly used software implement a forgiving parser? Possibly it was merely the text editor used by whatever IERS staff member made the file. TZDB switched from the NIST version to the IERS version because the latter is authoritative, is more up-to-date, and is easier to obtain. There was quite a bit of discussion of this on the tz mailing list. > * What is the history of the leap-seconds.list file and file format? I guess it was originally designed by Judah Levine of NIST. You might ask him for details (email address in the old version). Here is the history I have: https://github.com/eggert/tz/commits/main/leap-seconds.list But this goes back only to 2013. The full history surely goes further back than that. > * Is the format for leap-seconds.list defined? Where and how strongly? It's defined only by the comments in the file itself. > * 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? I suggest writing to the IERS (contact info in the file). You might also write Martin Burnicki who's been our liaison with the IERS and who has contributed to the tz mailing list. > * Could at least the spaces be changed back to tabs? That's up to the IERS, I think. I'd rather that TZDB's copy be byte-for-byte identical. From martin.burnicki at meinberg.de Wed Feb 7 09:17:06 2024 From: martin.burnicki at meinberg.de (Martin Burnicki) Date: Wed, 7 Feb 2024 10:17:06 +0100 Subject: [tz] leap-seconds.list format In-Reply-To: References: Message-ID: Byron Torres via tz wrote: > 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]. Beside the file from NIST, there has been a version of the leap second file provided by USNO, with quite different comments. Even the comments in different releases of the file from NIST have changed over the years, from rewording the comments, spaces inside the comment lines, and even different email addresses for the contact person at NIST, Judah Levine. In my opinion the most important thing to keep in mind is whether the source is authoritative and the file can be downloaded securely, i.e. via https rather than ftp. You could also check the hash of the file that is part of the data in the file, but the hash only verifies the integrity of the file. This may have been important at the time when the file format was invented (~2000) and it was downloaded via a modem/serial connection to detect transmission errors, but IMO this is obsolete today when you download the file e.g. via tcp/https. Is there a specific reason why your parser also checks the *comments* of the file, and distinguishes between tabs and spaces? From my perspective as a software developer, that doesn't sound very sensible. IMO, comments should simply be ignored, and tabs or spaces should simply be considered white space. That's e.g. how ntpd handles these files, and ntpd accepts any of the (old or newer) files from NIST, the old files from USNO, and files provided by IERS. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki at meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Gesch?ftsf?hrer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From brian.inglis at systematicsw.ab.ca Wed Feb 7 15:03:07 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Wed, 7 Feb 2024 08:03:07 -0700 Subject: [tz] leap-seconds.list format In-Reply-To: References: Message-ID: On 2024-02-07 02:17, Martin Burnicki via tz wrote: > Byron Torres via tz wrote: >> 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]. > > Beside the file from NIST, there has been a version of the leap second file > provided by USNO, with quite different comments. > > Even the comments in different releases of the file from NIST have changed over > the years, from rewording the comments, spaces inside the comment lines, and > even different email addresses for the contact person at NIST, Judah Levine. > > In my opinion the most important thing to keep in mind is whether the source is > authoritative and the file can be downloaded securely, i.e. via https rather > than ftp. > > You could also check the hash of the file that is part of the data in the file, > but the hash only verifies the integrity of the file. This may have been > important at the time when the file format was invented (~2000) and it was > downloaded via a modem/serial connection to detect transmission errors, but IMO > this is obsolete today when you download the file e.g. via tcp/https. > > Is there a specific reason why your parser also checks the *comments* of the > file, and distinguishes between tabs and spaces? > > From my perspective as a software developer, that doesn't sound very sensible. > IMO, comments should simply be ignored, and tabs or spaces should simply be > considered white space. That's e.g. how ntpd handles these files, and ntpd > accepts any of the (old or newer) files from NIST, the old files from USNO, and > files provided by IERS. IIRC the leap-seconds.list file loosely follows the format used by NTP for digital security certificate files generated by ntp-keygen. -- 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 From tim at timtimeonline.com Wed Feb 7 17:04:34 2024 From: tim at timtimeonline.com (Tim Parenti) Date: Wed, 7 Feb 2024 12:04:34 -0500 Subject: [tz] leap-seconds.list format In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 at 17:26, Byron Torres via tz wrote: > 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. > I believe you're misunderstanding what has actually happened here. To be clear: neither IERS nor NIST has (significantly) changed how they have been publishing their respective leap-seconds.list files. You are probably instead seeing the effects of tzdb's recent switch from republishing the NIST flavor of this file, which uses tabs, to republishing the IERS flavor, which uses spaces. You can see that the changes to the IERS flavor of leap-seconds.list have actually been quite modest over the last ~9 years by listing the ntp/ directory and comparing: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.3637008000 from 2015-04-03 with https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.3913697179 from 2024-01-09 In particular, spaces have been used consistently by IERS, and the comments have only changed in a few minor rewordings and typos over the years. On the other hand, the NIST flavor has had tabs for at least the last decade. Although they don't keep old versions available on FTP, you can see tzdb's captured history of the NIST version of the file here: https://github.com/eggert/tz/commits/27b4d76d1f6f9987bedb4e0b16369779020a9c97/leap-seconds.list As Paul has already mentioned, we recently made the switch from the NIST flavor to the IERS flavor after much discussion because the latter is ultimately a more reliable, authoritative source. Case in point: While IERS published a new version of the file alongside their most recent 2024-01-09 announcement, today ? nearly a month later ? NIST's latest version is still dated 2023-08-06. While all of that renders a few of your original questions about motivations moot, more good information on the format expected by ntpd has been provided in the other replies. > * Could at least the spaces be changed back to tabs? For the reasons already discussed, this is unlikely. IERS have been using spaces consistently for quite a while. The other data files distributed by tzdb have long been tab/space-agnostic, so our general response is that parsers should be, too. -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: From b at torresjrjr.com Wed Feb 7 21:48:01 2024 From: b at torresjrjr.com (Byron Torres) Date: Wed, 07 Feb 2024 21:48:01 +0000 Subject: [tz] leap-seconds.list format In-Reply-To: References: Message-ID: Thank you, Steve, Paul, Martin, Brian, Tim for your informative responses, resources and clarifications. On Wed Feb 7, 2024 at 3:03 PM GMT, Brian Inglis wrote: > IIRC the leap-seconds.list file loosely follows the format used by NTP for > digital security certificate files generated by ntp-keygen. Interesting. On Wed Feb 7, 2024 at 5:04 PM GMT, Tim Parenti wrote: > The other data files distributed by tzdb have long been tab/space-agnostic, > so our general response is that parsers should be, too. Seems like the way forward for Hare. I was hoping to coordinate a formal definition of the current informal format, defined apart from the file as a separate document, perhaps even an RFC, or even for a newer format. However, the file format seems sensible and stable enough currently, and I am satisfied with moving on. Again, thank you all b From martin.burnicki at meinberg.de Thu Feb 8 14:21:51 2024 From: martin.burnicki at meinberg.de (Martin Burnicki) Date: Thu, 8 Feb 2024 15:21:51 +0100 Subject: [tz] leap-seconds.list format In-Reply-To: References: Message-ID: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> Byron Torres via tz wrote: > Thank you, Steve, Paul, Martin, Brian, Tim for your informative > responses, resources and clarifications. > > On Wed Feb 7, 2024 at 3:03 PM GMT, Brian Inglis wrote: >> IIRC the leap-seconds.list file loosely follows the format used by NTP for >> digital security certificate files generated by ntp-keygen. > > Interesting. > > On Wed Feb 7, 2024 at 5:04 PM GMT, Tim Parenti wrote: >> The other data files distributed by tzdb have long been tab/space-agnostic, >> so our general response is that parsers should be, too. > > Seems like the way forward for Hare. > > I was hoping to coordinate a formal definition of the current informal > format, defined apart from the file as a separate document, perhaps even > an RFC, or even for a newer format. > > However, the file format seems sensible and stable enough currently, > and I am satisfied with moving on. I've put an informational page together which provides some basic information on the NTP leap second file: https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file At the bottom of the page there are links to the original paper which introduces the leap second file, and ways to use it. The paper explains the suggested file format, but it doesn't tell whether the white space between data fields should (or must) be tabs or spaces. Please note that some special fields like the expiration date were introduced later. So my previous suggestion remains: - Ignore all comment lines except the special ones starting with "#$", "#@", or "#h", which have special meanings. - Treat tabs or spaces between data fields in the same way, as field separators. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki at meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Gesch?ftsf?hrer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From brian.inglis at systematicsw.ab.ca Thu Feb 8 18:43:46 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Thu, 8 Feb 2024 11:43:46 -0700 Subject: [tz] leap-seconds.list format In-Reply-To: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> Message-ID: <2b21a083-9013-4853-8456-76538040639a@systematicsw.ab.ca> On 2024-02-08 07:21, Martin Burnicki via tz wrote: > Byron Torres via tz wrote: >> Thank you, Steve, Paul, Martin, Brian, Tim for your informative >> responses, resources and clarifications. >> >> On Wed Feb 7, 2024 at 3:03 PM GMT, Brian Inglis wrote: >>> IIRC the leap-seconds.list file loosely follows the format used by NTP for >>> digital security certificate files generated by ntp-keygen. >> >> Interesting. >> >> On Wed Feb 7, 2024 at 5:04 PM GMT, Tim Parenti wrote: >>> The other data files distributed by tzdb have long been tab/space-agnostic, >>> so our general response is that parsers should be, too. >> >> Seems like the way forward for Hare. >> >> I was hoping to coordinate a formal definition of the current informal >> format, defined apart from the file as a separate document, perhaps even >> an RFC, or even for a newer format. >> >> However, the file format seems sensible and stable enough currently, >> and I am satisfied with moving on. > > I've put an informational page together which provides some basic information on > the NTP leap second file: > https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file > > At the bottom of the page there are links to the original paper which introduces > the leap second file, and ways to use it. > > The paper explains the suggested file format, but it doesn't tell whether the > white space between data fields should (or must) be tabs or spaces. > > Please note that some special fields like the expiration date were introduced > later. > > So my previous suggestion remains: > > - Ignore all comment lines except the special ones starting with "#$", "#@", or > "#h", which have special meanings. > > - Treat tabs or spaces between data fields in the same way, as field separators. Also, considering the rules for sha1 hash generation and validation, and this is likely to continue to be the case if a better modern hash is added, only the numeric digits in the uncommented portions and special comment lines should be considered significant data: everything else is documentation for human consumption only. -- 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 From b at torresjrjr.com Thu Feb 8 21:20:22 2024 From: b at torresjrjr.com (Byron Torres) Date: Thu, 08 Feb 2024 21:20:22 +0000 Subject: [tz] leap-seconds.list format In-Reply-To: <2b21a083-9013-4853-8456-76538040639a@systematicsw.ab.ca> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <2b21a083-9013-4853-8456-76538040639a@systematicsw.ab.ca> Message-ID: On Thu Feb 8, 2024 at 6:43 PM GMT, brian.inglis--- via tz wrote: > On 2024-02-08 07:21, Martin Burnicki via tz wrote: > > I've put an informational page together which provides some basic information on > > the NTP leap second file: > > https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file This page and site is highly informative. A great reference for actual low-level timekeeping (and great for Hare). Thank you for sharing! > > So my previous suggestion remains: > > > > - Ignore all comment lines except the special ones starting with "#$", "#@", or > > "#h", which have special meanings. > > > > - Treat tabs or spaces between data fields in the same way, as field separators. > > Also, considering the rules for sha1 hash generation and validation, and this is > likely to continue to be the case if a better modern hash is added, only the > numeric digits in the uncommented portions and special comment lines should be > considered significant data: everything else is documentation for human > consumption only. Yes. Thanks again b From eggert at cs.ucla.edu Fri Feb 9 02:22:51 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 8 Feb 2024 18:22:51 -0800 Subject: [tz] leap-seconds.list format In-Reply-To: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> Message-ID: On 2/8/24 06:21, Martin Burnicki via tz wrote: > https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file Thanks, I installed the attached patch to refer to that page. A few comments about its contents: > For higher security the file should be signed using a public key certificate which can also be checked after the file has already been downloaded. However, this is currently not implemented As per Internet RFC 6557 (2012) section 3, TZDB distributions are signed via a PGP signature. This signature is published in each distribution's announcement, so effectively you can obtain a signed leap-seconds.list from a TZDB distribution. This practice started in 2012e, in response to the RFC. Also, TZDB releases have signed tags in the Github development repository; this is another way to verify leap-seconds.list Admittedly neither of these techniques are the same as having the IERS sign the file, which would be preferable. > The IETF website https://www.ietf.org/timezones/data/ used to provide the files extracted from the latest TZ DB distribution archive, but this no longer appears to be the case . Yes, I think that has been retired; Kim Davies could confirm that if he has the time. One other link you might want to mention is: https://raw.githubusercontent.com/eggert/tz/main/leap-seconds.list This is the latest version of leap-seconds.list in the TZDB development repository. It is more up-to-date than , though less up-to-date than the IERS primary copy. Github likely resists DDoS attacks better than the other sites; see . -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Cite-The-NTP-Leap-Second-File.patch Type: text/x-patch Size: 2492 bytes Desc: not available URL: From brian.inglis at systematicsw.ab.ca Fri Feb 9 22:20:25 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Fri, 9 Feb 2024 15:20:25 -0700 Subject: [tz] leap-seconds.list format In-Reply-To: References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> Message-ID: <27b66516-107a-41e1-aa5a-435697bab7bd@systematicsw.ab.ca> On 2024-02-08 19:22, Paul Eggert via tz wrote: > On 2/8/24 06:21, Martin Burnicki via tz wrote: > >> https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file > > Thanks, I installed the attached patch to refer to that page. > > A few comments about its contents: > >> For higher security the file should be signed using a public key certificate >> which can also be checked after the file has already been downloaded. However, >> this is currently not implemented You can check leap-seconds.list sha1 using one of the programs from IERS or NIST noted in their respective files, or a script to do the same using sha1sum and other utilities, plus diff (-b) against the previous copy to ensure minimal other changes. > As per Internet RFC 6557 (2012) section 3, TZDB distributions are signed via a > PGP signature. This signature is published in each distribution's announcement, > so effectively you can obtain a signed leap-seconds.list from a TZDB > distribution. This practice started in 2012e, in response to the RFC. > > Also, TZDB releases have signed tags in the Github development repository; this > is another way to verify leap-seconds.list > > Admittedly neither of these techniques are the same as having the IERS sign the > file, which would be preferable. > >> The IETF website https://www.ietf.org/timezones/data/ used to provide the >> files extracted from the latest TZ DB distribution archive, but this no longer >> appears to be the case . > > Yes, I think that has been retired; Kim Davies could confirm that if he has the > time. > > One other link you might want to mention is: > > https://raw.githubusercontent.com/eggert/tz/main/leap-seconds.list > > This is the latest version of leap-seconds.list in the TZDB development > repository. It is more up-to-date than > , though less > up-to-date than the IERS primary copy. Github likely resists DDoS attacks better > than the other sites; see . -- 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 From eggert at cs.ucla.edu Sat Feb 10 01:26:14 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 9 Feb 2024 17:26:14 -0800 Subject: [tz] leap-seconds.list format In-Reply-To: <27b66516-107a-41e1-aa5a-435697bab7bd@systematicsw.ab.ca> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <27b66516-107a-41e1-aa5a-435697bab7bd@systematicsw.ab.ca> Message-ID: <93ef236e-a85f-4ace-91c3-c73a71983726@cs.ucla.edu> On 2024-02-09 14:20, brian.inglis--- via tz wrote: >> On 2/8/24 06:21, Martin Burnicki via tz wrote: >>> For higher security the file should be signed using a public key >>> certificate ... > > You can check leap-seconds.list sha1 That SHA1 checksum merely checks for data corruption. Martin was asking for a signature via a public key certificate. Such a signature also verifies that the sender is not some random attacker; this is a stronger guarantee than a checksum. This is why TZDB releases have signed tags on GitHub and why release announcements contain the tarballs' PGP signatures. From brian.inglis at systematicsw.ab.ca Sun Feb 11 00:22:18 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Sat, 10 Feb 2024 17:22:18 -0700 Subject: [tz] leap-seconds.list format In-Reply-To: <93ef236e-a85f-4ace-91c3-c73a71983726@cs.ucla.edu> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <27b66516-107a-41e1-aa5a-435697bab7bd@systematicsw.ab.ca> <93ef236e-a85f-4ace-91c3-c73a71983726@cs.ucla.edu> Message-ID: On 2024-02-09 18:26, Paul Eggert wrote: > On 2024-02-09 14:20, brian.inglis--- via tz wrote: >>> On 2/8/24 06:21, Martin Burnicki via tz wrote: >>>> For higher security the file should be signed using a public key certificate >>>> ... >> >> You can check leap-seconds.list sha1 > > That SHA1 checksum merely checks for data corruption. Martin was asking for a > signature via a public key certificate. Such a signature also verifies that the > sender is not some random attacker; this is a stronger guarantee than a > checksum. This is why TZDB releases have signed tags on GitHub and why release > announcements contain the tarballs' PGP signatures. I am aware of that, and was suggesting all we can do for now with the current distribution: using https:// as you suggested, sha1 check, and eyeball diff (-b) in case of site hacks. I left the remainder of the post intact with information of useful additions. I previously suggested to the folks at IERS they include an additional updated hash (#H?) or detached signature, when providing feedback on leap-second files issued with expiry dates earlier than the issue date of the next Bulletin C. Currently document digital signature certs appear to be restricted to structured document types to which a digital signature subtype can be added e.g. PDF/*Office. It appears that only a generic cert for hpiers.obspm.fr could be used to create a detached (armored) signature. -- 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 From eggert at cs.ucla.edu Sun Feb 11 01:34:17 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sat, 10 Feb 2024 17:34:17 -0800 Subject: [tz] leap-seconds.list format In-Reply-To: References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <27b66516-107a-41e1-aa5a-435697bab7bd@systematicsw.ab.ca> <93ef236e-a85f-4ace-91c3-c73a71983726@cs.ucla.edu> Message-ID: <167af2c6-b41f-4ac2-8141-8b3617a38293@cs.ucla.edu> On 2024-02-10 16:22, brian.inglis--- via tz wrote: > all we can do for now with the > current distribution: using https:// as you suggested, sha1 check, and > eyeball diff (-b) in case of site hacks. I guess I'm not following your point because that's clearly not all a user can do. A user can also check the signatures, which are made via a public key certificate. I know a few users do that, because I got email a while back when my public key expired and was renewed. From brian.inglis at systematicsw.ab.ca Sun Feb 11 21:45:48 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Sun, 11 Feb 2024 14:45:48 -0700 Subject: [tz] leap-seconds.list format In-Reply-To: <167af2c6-b41f-4ac2-8141-8b3617a38293@cs.ucla.edu> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <27b66516-107a-41e1-aa5a-435697bab7bd@systematicsw.ab.ca> <93ef236e-a85f-4ace-91c3-c73a71983726@cs.ucla.edu> <167af2c6-b41f-4ac2-8141-8b3617a38293@cs.ucla.edu> Message-ID: <65cbd934-f447-4b90-acd7-1e23181512b7@systematicsw.ab.ca> On 2024-02-10 18:34, Paul Eggert wrote: > On 2024-02-10 16:22, brian.inglis--- via tz wrote: >> all we can do for now with the current distribution: using https:// as you >> suggested, sha1 check, and eyeball diff (-b) in case of site hacks. > I guess I'm not following your point because that's clearly not all a user can > do. A user can also check the signatures, which are made via a public key > certificate. I know a few users do that, because I got email a while back when > my public key expired and was renewed. I was referring solely to the original IERS source files leap-seconds.{[0-9]{10,},list} and all we can do for now to validate them, using sha1 and eyeball. We could also check that the new external time stamp file suffix agrees with the internal "#$" line update validity NTP time stamp, and that is (normally) in the current month January or July, and less than the "#@" line expiry NTP time stamp, (normally) eleven months later on 28th June or December, and that date agrees with the formatted date in the preceding "expires" comment line. With known access to the current/previous leap-seconds.list sym-/link or .[0-9]{9,} target, we could also check that the update validity time stamp is (normally) between the current/previous update validity and expiry time stamps. -- 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 From martin.burnicki at meinberg.de Mon Feb 12 18:33:55 2024 From: martin.burnicki at meinberg.de (Martin Burnicki) Date: Mon, 12 Feb 2024 19:33:55 +0100 Subject: [tz] leap-seconds.list format In-Reply-To: References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> Message-ID: Paul Eggert wrote: > On 2/8/24 06:21, Martin Burnicki via tz wrote: > >> https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file > > Thanks, I installed the attached patch to refer to that page. Thanks! > A few comments about its contents: > >> For higher security the file should be signed using a public key >> certificate which can also be checked after the file has already been >> downloaded. However, this is currently not implemented > > As per Internet RFC 6557 (2012) section 3, TZDB distributions are signed > via a PGP signature. This signature is published in each distribution's > announcement, so effectively you can obtain a signed leap-seconds.list > from a TZDB distribution. This practice started in 2012e, in response to > the RFC. > > Also, TZDB releases have signed tags in the Github development > repository; this is another way to verify leap-seconds.list > > Admittedly neither of these techniques are the same as having the IERS > sign the file, which would be preferable. I've now made a few changes to my page: All occurrences of "TZ DB" have been replaced with "TZDB". The section about the TAI Offset Table https://wiki.py.meinberg.de/kb:time_sync:ntp:configuration:ntp_leap_second_file#tai_offset_table now contains a note that the leap second table can use space or tabs as field separators, depending on the origin of the file. The section about the SHA1 hash now mentions the signature of the TZDB version https://wiki.py.meinberg.de/kb:time_sync:ntp:configuration:ntp_leap_second_file#sha1_hash The section about the TZDB/IANA version now mentions the signatures. [...] > One other link you might want to mention is: > > https://raw.githubusercontent.com/eggert/tz/main/leap-seconds.list > > This is the latest version of leap-seconds.list in the TZDB development > repository. It is more up-to-date than > , though less > up-to-date than the IERS primary copy. Github likely resists DDoS > attacks better than the other sites; see > . @Paul: I've added the URL to my page. Please let me know if I should keep the other links to the Github repo and your homepage, or whether I should remove them. Concerning the PGP signatures of the download archives: IMO checking the signatures would be much easier for potential users of the .gz or .lz archives if the signatures would be available for download as files at https://www.iana.org/time-zones, e.g. tzdb-2024a.tar.lz.asc for an ASCII signature, or tzdb-2024a.tar.lz.sig for a binary signature. Doing so would make this very much easier for folks who just come across the download page, but are not on (one of) the mailing list(s). I have to admit that I didn't even notice that the signatures are part of the announcement emails because I usually just read the subject if it just tells that a new TZDB version has been released. I also find it much harder to copy a signature text block from an email to verify the integrity of a downloaded file. At Meinberg, I provide this information as file, see e.g. https://www.meinbergglobal.com/english/sw/#linux so it's very easy to download the .gz file and the signature file an run a simple command line program to verify the integrity. Just my 2 ct. ;-) Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki at meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Gesch?ftsf?hrer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From eggert at cs.ucla.edu Mon Feb 12 21:07:16 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 12 Feb 2024 13:07:16 -0800 Subject: [tz] leap-seconds.list format In-Reply-To: References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> Message-ID: <31fa9a3e-d351-45c2-b972-abc9efe90347@cs.ucla.edu> On 2/12/24 10:33, Martin Burnicki wrote: > @Paul: I've added the URL to my page. Please let me know if I should > keep the other links to the Github repo and your homepage, or whether I > should remove them. I'd keep them, thanks. > Concerning the PGP signatures of the download archives: > > IMO checking the signatures would be much easier for potential users of > the .gz or .lz archives if the signatures would be available for > download as files at https://www.iana.org/time-zones, e.g. > > tzdb-2024a.tar.lz.asc for an ASCII signature, or > tzdb-2024a.tar.lz.sig for a binary signature. Yes, they're available, e.g.,: https://data.iana.org/time-zones/releases/tzdb-2024a.tar.lz.asc and similarly for tzcode and tzdata. Perhaps there should be be links to these signatures from , in another column of the "Latest version" table. From brian.inglis at systematicsw.ab.ca Mon Feb 12 23:34:11 2024 From: brian.inglis at systematicsw.ab.ca (brian.inglis at systematicsw.ab.ca) Date: Mon, 12 Feb 2024 16:34:11 -0700 Subject: [tz] leap-seconds.list format In-Reply-To: <31fa9a3e-d351-45c2-b972-abc9efe90347@cs.ucla.edu> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <31fa9a3e-d351-45c2-b972-abc9efe90347@cs.ucla.edu> Message-ID: On 2024-02-12 14:07, Paul Eggert via tz wrote: > On 2/12/24 10:33, Martin Burnicki wrote: > >> @Paul: I've added the URL to my page. Please let me know if I should keep the >> other links to the Github repo and your homepage, or whether I should remove >> them. > > I'd keep them, thanks. > >> Concerning the PGP signatures of the download archives: >> >> IMO checking the signatures would be much easier for potential users of the >> .gz or .lz archives if the signatures would be available for download as files >> at https://www.iana.org/time-zones, e.g. >> >> tzdb-2024a.tar.lz.asc for an ASCII signature, or >> tzdb-2024a.tar.lz.sig for a binary signature. > > Yes, they're available, e.g.,: > > https://data.iana.org/time-zones/releases/tzdb-2024a.tar.lz.asc > > and similarly for tzcode and tzdata. > > Perhaps there should be be links to these signatures from > , in another column of the "Latest version" table. Also info please on any valid signing keys and preferred keyservers. -- 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 From eggert at cs.ucla.edu Tue Feb 13 00:19:35 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 12 Feb 2024 16:19:35 -0800 Subject: [tz] leap-seconds.list format In-Reply-To: <65cbd934-f447-4b90-acd7-1e23181512b7@systematicsw.ab.ca> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <27b66516-107a-41e1-aa5a-435697bab7bd@systematicsw.ab.ca> <93ef236e-a85f-4ace-91c3-c73a71983726@cs.ucla.edu> <167af2c6-b41f-4ac2-8141-8b3617a38293@cs.ucla.edu> <65cbd934-f447-4b90-acd7-1e23181512b7@systematicsw.ab.ca> Message-ID: <5fdac1dc-821c-4457-8ad2-06369f93aae0@cs.ucla.edu> On 2/11/24 13:45, brian.inglis--- via tz wrote: > I was referring solely to the original IERS source files > leap-seconds.{[0-9]{10,},list} and all we can do for now to validate > them, using sha1 and eyeball. If I understand this correctly, the worry is that an attacker would somehow convince us that a leap second would occur on (say) December 31, 2024 and talk us into installing a bogus leap-seconds.list file into the development repository, and that we'd then generate a new TZDB release. Such a release would contain a leap-seconds.list file that was signed by us, but incorrect. I'd place this low on the list of things to worry about. Although it'd be better if the IERS signed their files, we publicize leap second updates on the TZDB mailing list and it seems unlikely such an attack would go unnoticed and unremarked upon before a TZDB release. From martin.burnicki at meinberg.de Tue Feb 13 17:31:10 2024 From: martin.burnicki at meinberg.de (Martin Burnicki) Date: Tue, 13 Feb 2024 18:31:10 +0100 Subject: [tz] leap-seconds.list format In-Reply-To: <31fa9a3e-d351-45c2-b972-abc9efe90347@cs.ucla.edu> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <31fa9a3e-d351-45c2-b972-abc9efe90347@cs.ucla.edu> Message-ID: <71ae6e14-0e21-4cd1-aa9f-28fbd179acc3@meinberg.de> Paul Eggert wrote: > On 2/12/24 10:33, Martin Burnicki wrote: > >> @Paul: I've added the URL to my page. Please let me know if I should >> keep the other links to the Github repo and your homepage, or whether >> I should remove them. > > I'd keep them, thanks. > >> Concerning the PGP signatures of the download archives: >> >> IMO checking the signatures would be much easier for potential users >> of the .gz or .lz archives if the signatures would be available for >> download as files at https://www.iana.org/time-zones, e.g. >> >> tzdb-2024a.tar.lz.asc for an ASCII signature, or >> tzdb-2024a.tar.lz.sig for a binary signature. > > Yes, they're available, e.g.,: > > https://data.iana.org/time-zones/releases/tzdb-2024a.tar.lz.asc > > and similarly for tzcode and tzdata. > > Perhaps there should be be links to these signatures from > , in another column of the "Latest > version" table. Yes, that would be great. Otherwise, someone who just comes across the download page at IANA does't even know that signatures are available. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki at meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Gesch?ftsf?hrer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From des at des.no Fri Feb 16 13:23:26 2024 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 16 Feb 2024 14:23:26 +0100 Subject: [tz] Checked arithmetic bug In-Reply-To: (Paul Eggert's message of "Tue, 13 Feb 2024 11:38:14 -0800 (2 days, 17 hours, 17 minutes ago)") References: Message-ID: <86ttm81r1t.fsf@ltc.des.no> 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 at des.no -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-increment_overflow-preserve-the-original-value-on-ov.patch Type: text/x-patch Size: 1738 bytes Desc: not available URL: From eggert at cs.ucla.edu Sat Feb 17 07:36:46 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 16 Feb 2024 23:36:46 -0800 Subject: [tz] Checked arithmetic bug In-Reply-To: <86ttm81r1t.fsf@ltc.des.no> References: <86ttm81r1t.fsf@ltc.des.no> Message-ID: On 2024-02-16 05:23, Dag-Erling Sm?rgrav via tz wrote: > 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(). Thanks for the bug report. I installed the attached, which attacks the problem in a different way, similar to the way it's already attacked a few lines later. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Port-unlikely-overflow-check-to-C23.patch Type: text/x-patch Size: 1255 bytes Desc: not available URL: From eggert at cs.ucla.edu Mon Feb 19 07:34:42 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 18 Feb 2024 23:34:42 -0800 Subject: [tz] timezone-related error sparks $340 million lawsuit Message-ID: 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-win-error From martin.burnicki at meinberg.de Mon Feb 19 10:22:12 2024 From: martin.burnicki at meinberg.de (Martin Burnicki) Date: Mon, 19 Feb 2024 11:22:12 +0100 Subject: [tz] leap-seconds.list format In-Reply-To: <31fa9a3e-d351-45c2-b972-abc9efe90347@cs.ucla.edu> References: <52dc9190-6ec5-4d42-a135-af5eabbbd583@meinberg.de> <31fa9a3e-d351-45c2-b972-abc9efe90347@cs.ucla.edu> Message-ID: <44aa2a13-c403-43ae-b62c-7a25b1237d38@meinberg.de> Paul Eggert wrote: [...] > Perhaps there should be be links to these signatures from > , in another column of the "Latest > version" table. Just FYI: I have now also created a PGP/GPG signature file for the copy of the IERS leap second file available via the Meinberg web site: https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file#the_leap_second_file_at_meinberg The main reason Meinberg provides a copy of this file is that many time server devices manufactured by Meinberg periodically check for an update to the leap second file. If the file is available via the Meinberg website, this does not place any load on the IERS web server. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki at meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Gesch?ftsf?hrer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From kim.davies at iana.org Mon Feb 19 18:52:25 2024 From: kim.davies at iana.org (Kim Davies) Date: Mon, 19 Feb 2024 18:52:25 +0000 Subject: [tz] Administrivia: Mailing List Archives Message-ID: <1903F98E-AAC6-4174-94A2-B36058979731@iana.org> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois at astro.ch Sun Feb 25 17:30:41 2024 From: alois at astro.ch (Alois Treindl) Date: Sun, 25 Feb 2024 18:30:41 +0100 Subject: [tz] Administrivia: Mailing List Archives -- test In-Reply-To: <1903F98E-AAC6-4174-94A2-B36058979731@iana.org> References: <1903F98E-AAC6-4174-94A2-B36058979731@iana.org> Message-ID: Is the mailing list working? On 19.02.24 19:52, Kim Davies via tz wrote: > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois at astro.ch Thu Feb 29 11:30:45 2024 From: alois at astro.ch (Alois Treindl) Date: Thu, 29 Feb 2024 12:30:45 +0100 Subject: [tz] error Portugal 1980 Message-ID: <146cc1bf-21da-4eea-8017-a2b4e97185d3@astro.ch> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- diff --git a/europe b/europe index c6b52703..855ec46e 100644 --- a/europe +++ b/europe @@ -2145,10 +2145,11 @@ Rule Port 1947 1965 - Apr Sun>=1 2:00s 1:00 S Rule Port 1947 1965 - Oct Sun>=1 2:00s 0 - Rule Port 1977 only - Mar 27 0:00s 1:00 S Rule Port 1977 only - Sep 25 0:00s 0 - -Rule Port 1978 1979 - Apr Sun>=1 0:00s 1:00 S +#Rule Port 1978 1979 - Apr Sun>=1 0:00s 1:00 S +Rule Port 1978 1980 - Apr Sun>=1 0:00s 1:00 S 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 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 # From alois at astro.ch Thu Feb 29 12:12:45 2024 From: alois at astro.ch (Alois Treindl) Date: Thu, 29 Feb 2024 13:12:45 +0100 Subject: [tz] error Portugal 1980 In-Reply-To: <146cc1bf-21da-4eea-8017-a2b4e97185d3@astro.ch> References: <146cc1bf-21da-4eea-8017-a2b4e97185d3@astro.ch> Message-ID: I now also found the law text. On 29.02.24 12:30, Alois Treindl via tz wrote: > Portaria n? 69/80 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 02700270.pdf Type: application/pdf Size: 93624 bytes Desc: not available URL: From arthurdavidolson at gmail.com Thu Feb 29 13:56:54 2024 From: arthurdavidolson at gmail.com (Arthur David Olson) Date: Thu, 29 Feb 2024 08:56:54 -0500 Subject: [tz] Happy Leap Day... Message-ID: ...to those who celebrate; Happy March 0 to those who don't. @dashdashado -------------- next part -------------- An HTML attachment was scrubbed... URL: From sla at ucolick.org Thu Feb 29 14:11:36 2024 From: sla at ucolick.org (Steve Allen) Date: Thu, 29 Feb 2024 06:11:36 -0800 Subject: [tz] Happy Leap Day... In-Reply-To: References: Message-ID: <20240229141136.GA26670@ucolick.org> On Thu 2024-02-29T08:56:54-0500 Arthur David Olson via tz hath writ: > ...to those who celebrate; Happy March 0 to those who don't. Alas, I already celebrated Sunday on the bissextus. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m From skilpat at gmail.com Thu Feb 29 14:16:55 2024 From: skilpat at gmail.com (Scott Kilpatrick) Date: Thu, 29 Feb 2024 09:16:55 -0500 Subject: [tz] Happy Leap Day... In-Reply-To: <20240229141136.GA26670@ucolick.org> References: <20240229141136.GA26670@ucolick.org> Message-ID: Turns out it's the first 25-hour Leap Day of the new millennium (in Eastern Kazakhstan). Happy Leap Day indeed! https://typesandtimes.net/2024/02/kazakhstan-25-hour-leap-years On Thu, Feb 29, 2024 at 9:12?AM Steve Allen via tz wrote: > On Thu 2024-02-29T08:56:54-0500 Arthur David Olson via tz hath writ: > > ...to those who celebrate; Happy March 0 to those who don't. > > Alas, I already celebrated Sunday on the bissextus. > > -- > Steve Allen WGS-84 (GPS) > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat > +36.99855 > 1156 High Street Voice: +1 831 459 3046 Lng > -122.06015 > Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at timtimeonline.com Thu Feb 29 14:55:07 2024 From: tim at timtimeonline.com (Tim Parenti) Date: Thu, 29 Feb 2024 09:55:07 -0500 Subject: [tz] error Portugal 1980 In-Reply-To: <146cc1bf-21da-4eea-8017-a2b4e97185d3@astro.ch> References: <146cc1bf-21da-4eea-8017-a2b4e97185d3@astro.ch> Message-ID: On Thu, 29 Feb 2024 at 06:31, Alois Treindl via tz wrote: > I think there is an error in TZ, regarding begin of DST in Portugal in > 1980. > Some time ago, I'd looked into some other changes for Portugal and found that our data there, which is mostly from Shanks, likely needs a complete overhaul, much like I did for Uruguay in 2018 . I'd made significant progress on this, working on data from Observat?rio Astron?mico de Lisboa, before more important things came up and I had to shelve the branch. I just checked, and it seems I'd ended up with "Apr Sun>=1 1:00s" for 1980, which is equivalent to the law text you provided (at least for the mainland, "1 hora de tempo universal"), but not quite to your patch. But, for example, I'd also had that for 1978 and 1979 as well, which is an hour different to what's currently in tzdb for those years. If you'll allow me a few days to dust off and clean up what I had already for the mainland, I'd rather we take the time to ensure this is done right and not commit changes here in a piecemeal fashion. I imagine there might be a couple revisions before it ultimately lands in the repo, but as this is all historical there is no urgency. One thing I *know* I could use help with, and that we need to be careful of, is figuring out how changes to 'Port' rules, in use until 1983, affect Azores and Madeira. Since we seem to know that Portugal didn't harmonize with EU DST practice until 1992, I wouldn't want to guess that that's what was done 1916?1983. So if someone could help find *some* relevant text from that period, that would really help. https://diariodarepublica.pt/ -- Tim Parenti -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Inglis at SystematicSW.ab.ca Thu Feb 29 19:47:44 2024 From: Brian.Inglis at SystematicSW.ab.ca (Brian Inglis) Date: Thu, 29 Feb 2024 12:47:44 -0700 Subject: [tz] NZ Leap Day Self Pay Petrol Pump Failures Message-ID: https://arstechnica.com/gadgets/2024/02/leap-year-glitch-broke-self-pay-pumps-across-new-zealand-for-over-10-hours/ -- 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 From alois at astro.ch Thu Feb 29 21:17:17 2024 From: alois at astro.ch (Alois Treindl) Date: Thu, 29 Feb 2024 22:17:17 +0100 Subject: [tz] error Portugal 1980 In-Reply-To: References: <146cc1bf-21da-4eea-8017-a2b4e97185d3@astro.ch> Message-ID: An HTML attachment was scrubbed... URL: From eggert at cs.ucla.edu Thu Feb 29 21:22:47 2024 From: eggert at cs.ucla.edu (Paul Eggert) Date: Thu, 29 Feb 2024 13:22:47 -0800 Subject: [tz] NZ Leap Day Self Pay Petrol Pump Failures In-Reply-To: References: Message-ID: <4b59e59f-b897-4961-8494-92a76d82dcce@cs.ucla.edu> In related news, leap day also broke the issuance of driver's licenses in four prefectures in Japan. This occurred at about 20:15 local time, or 11:15 UTC, so it's not clear how the leap day caused the problem - perhaps a once-a-day app run after the end of the work day? https://japannews.yomiuri.co.jp/society/general-news/20240229-171789/ Leap day also broke the videogames Theatrhythm and WRC. The workaround for the videogames is to change the date on your console. Reports of the bug have suggested that it be fixed by the year 2028. https://kotaku.com/final-fantasy-theatrhythm-broken-wrc-leap-day-bug-ps4-1851298039 https://bnnbreaking.com/tech/leap-day-glitch-in-theatrhythm-final-bar-line-disrupts-gameplay-awaiting-2028-fix