leap-seconds.list format
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/d0c057dbbb0f1ee9179769e187c0fbd3b00327... [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
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.
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@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
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
On Tue, 6 Feb 2024 at 17:26, Byron Torres via tz <tz@iana.org> 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/27b4d76d1f6f9987bedb4e0b16369779020a9c9... 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
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
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... 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@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
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...
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
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...
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
On 2/8/24 06:21, Martin Burnicki via tz wrote:
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second...
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 <https://data.iana.org/time-zones/tzdb/leap-seconds.list>, though less up-to-date than the IERS primary copy. Github likely resists DDoS attacks better than the other sites; see <https://github.blog/2018-03-01-ddos-incident-report/>.
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...
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 <https://data.iana.org/time-zones/tzdb/leap-seconds.list>, though less up-to-date than the IERS primary copy. Github likely resists DDoS attacks better than the other sites; see <https://github.blog/2018-03-01-ddos-incident-report/>.
-- 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
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.
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
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.
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
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.
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...
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_f... 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_f... 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 <https://data.iana.org/time-zones/tzdb/leap-seconds.list>, though less up-to-date than the IERS primary copy. Github likely resists DDoS attacks better than the other sites; see <https://github.blog/2018-03-01-ddos-incident-report/>.
@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@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
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 <https://www.iana.org/time-zones>, in another column of the "Latest version" table.
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 <https://www.iana.org/time-zones>, 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
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 <https://www.iana.org/time-zones>, 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@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
Paul Eggert wrote: [...]
Perhaps there should be be links to these signatures from <https://www.iana.org/time-zones>, 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... 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@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
participants (5)
-
brian.inglis＠systematicsw.ab.ca -
Byron Torres -
Martin Burnicki -
Paul Eggert -
Tim Parenti