Re: [tz] leap_second.list not updated after latest IERS Bulletin C
On 12/7/23 13:21, Geert Hendrickx wrote:
NTPsec logs the following at startup:
CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): good hash signature
CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): loaded, expire=2024-06-28T00:00Z last=2017-01-01T00:00Z ofs=37
So I *guess* (without having looked at the code) that it actually cares about the expiration date as well.
I think you're right NTPsec does care, though I vaguely recall that if the file has expired the only issue is an unwanted log message. If people are running NTPsec and configuring it to use TZDB's leap-seconds.list, that unwanted log message could be an issue. I just now checked the NTPsec source code, though, and by default it uses this URL: https://www.ietf.org/timezones/data/leap-seconds.list which hasn't worked in a while; the contents are simply "ietf.org is no longer serving this file." So it may be that we don't need to issue a new TZDB release merely because 2023c's leap-seconds.list will be out-of-date soon.
(but we periodically download it from IERS, not from TZ)
In that case your setup is OK as-is, though we may still need to hear from other people to see whether they're relying on the TZDB copy of leap-seconds.list. TZDB uses the NIST version of leap-seconds.list rather than the IERS version, as the NIST version is clearly public domain and so this way we don't have to worry about copyright issues. However, the IERS version should work fine with either NTPsec or with other downstream uses, such as TZDB itself (that is, if you're not worried about copyright).
On 12/7/2023 9:29 PM, Paul Eggert via tz wrote:
On 12/7/23 13:21, Geert Hendrickx wrote:
NTPsec logs the following at startup:
CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): good hash signature
CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): loaded, expire=2024-06-28T00:00Z last=2017-01-01T00:00Z ofs=37
So I *guess* (without having looked at the code) that it actually cares about the expiration date as well.
I think you're right NTPsec does care, though I vaguely recall that if the file has expired the only issue is an unwanted log message.
If people are running NTPsec and configuring it to use TZDB's leap-seconds.list, that unwanted log message could be an issue. I just now checked the NTPsec source code, though, and by default it uses this URL:
https://www.ietf.org/timezones/data/leap-seconds.list
which hasn't worked in a while; the contents are simply "ietf.org is no longer serving this file." So it may be that we don't need to issue a new TZDB release merely because 2023c's leap-seconds.list will be out-of-date soon.
(but we periodically download it from IERS, not from TZ)
In that case your setup is OK as-is, though we may still need to hear from other people to see whether they're relying on the TZDB copy of leap-seconds.list.
TZDB uses the NIST version of leap-seconds.list rather than the IERS version, as the NIST version is clearly public domain and so this way we don't have to worry about copyright issues. However, the IERS version should work fine with either NTPsec or with other downstream uses, such as TZDB itself (that is, if you're not worried about copyright).
In my opinion TzDb should update the leap-seconds.list date and issue a TzDb release because there's no telling who might be using it and perhaps relying on the expiry date. The current expiry date at https://ftp.iana.org/tz/tzdb-2023c/leap-seconds.list is # File expires on: 28 December 2023 The current expiry date at ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list is # File expires on: 28 June 2024 There are other sources at IERS besides Bulletin C. In my development work I've been using: https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat This file has a different form, using MJD rather than "number of seconds since 1 January 1900, 00:00:00". Note that, as I understand it, Bulletin C is the only official "product" of the IERS. But this Leap_Second_History.dat file has been being issued and maintained for years. I cannot comment expertly on "copyright", but it seems to me anything from IERS must be public domain, isn't it? How is it not? -Brooks
On 2023-12-08 11:58, Brooks Harris via tz wrote:
anything from IERS must be public domain, isn't it? How is it not?
It’s published in France and French law does not recognize the US notion of public domain. The French “domaine public” is more restrictive than the US notion, and as I understand things if published in France the file cannot be domaine public anyway; that can happen only 70 years after publication. The IERS version lacks a copyright notice, and it’s not clear who holds the copyright or under what terms TZDB could legally reproduce the file. The copyright holder might be the IERS, the Paris Observatory, Paris Sciences et Lettres University, the Ministry of National Education, or some other body. A while ago I asked for a proper copyright notice to be added, to clarify rights and establish permissions, but this has not gotten anywhere presumably because the people in charge of the IERS version are busy and don’t think this is important. Given the legal uncertainty it’s safer for TZDB to not copy the IERS version.
On 2023-12-08 13:58, Paul Eggert via tz wrote:
On 2023-12-08 11:58, Brooks Harris via tz wrote:
anything from IERS must be public domain, isn't it? How is it not?
The IERS version lacks a copyright notice, and it’s not clear who holds the copyright or under what terms TZDB could legally reproduce the file. The copyright holder might be the IERS, the Paris Observatory, Paris Sciences et Lettres University, the Ministry of National Education, or some other body. A while ago I asked for a proper copyright notice to be added, to clarify rights and establish permissions, but this has not gotten anywhere presumably because the people in charge of the IERS version are busy and don’t think this is important.
They are part of an international org in an EU org and may still be waiting for approval of the document specifying the application of the copyright, data, and database rights to the file and its data. ;^> [I read about one bureaucrat who had spent seven years thus far trying to get a document approved!] -- 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 Fri 2023-12-08T14:55:27-0700 Brian Inglis via tz hath writ:
[I read about one bureaucrat who had spent seven years thus far trying to get a document approved!]
A century ago the Paris bureau of the IERS, then the BIH, undertook activities which were not explicit in its charter, and as a result suffered greatly. At subsequent meetings when their oversight committee wanted them to undertake new activities the minutes document that the BIH director had to remind the oversight committee to write a draft directing them to perform the new duties and explicitly vote to record their approval of that document. As much as we all might like a copyright-free document, and perhaps even more, a digitally-signed authenticatable leap-seconds.list, I do not expect that to happen unless several international scientific bodies request the current overseeing body to produce a written directive telling the IERS to do that. -- Steve Allen <sla@ucolick.org> 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
On Fri, 8 Dec 2023 at 15:59, Paul Eggert via tz <tz@iana.org> wrote:
The IERS version lacks a copyright notice
It appears that https://hpiers.obspm.fr/iers/bul/bulc/README now contains a Creative Commons notice which covers the entire `bulc` directory: # The files in this directory and sub directories are licensed under the Creative Commons Attribution 4.0 : CC BY-ND 4.0 # http://creativecommons.org/licenses/by/4.0/ Based on the Wayback Machine and the directory listing at https://hpiers.obspm.fr/iers/bul/bulc/ it appears this change was made on 2022-07-07. The previous 2017-04-11 version of the notice, strictly speaking, only pertained to the README file itself, and not to the rest of the directory or its subdirectories: https://web.archive.org/web/20220528051035/https://hpiers.obspm.fr/iers/bul/... On Fri, 8 Dec 2023 at 16:56, Brian Inglis via tz <tz@iana.org> wrote:
[I read about one bureaucrat who had spent seven years thus far trying to get a document approved!]
This has been going along for about as long! It still falls short, though. of the ideal that the leap-seconds.list file itself also contain the notice so we (and others) don't have to duplicate it elsewhere: https://mm.icann.org/pipermail/tz/2017-April/024988.html It also doesn't necessarily allay the other concerns. But it's definitely some progress, at least. -- Tim Parenti
On 12/9/23 13:30, Tim Parenti wrote:
It still falls short, though. of the ideal that the leap-seconds.list file itself also contain the notice so we (and others) don't have to duplicate it elsewhere: https://mm.icann.org/pipermail/tz/2017-April/024988.html
It also doesn't necessarily allay the other concerns.
Perhaps we could work around the copyright-notice problem by adding appropriate verbiage to the LICENSE file. This would require some thinking, though. One other problem just occurred to me. Since the IERS variant of leap-seconds.list is not public domain, putting it into tzdata would contradict Internet RFC 6557 section 7 "Data Ownership"[1], which says that tzdata is public domain and therefore is exempt from a bunch of rules that I'm not familiar with and would rather not become expert in if I can avoid it. I suppose this could be worked around by writing a new RFC that addresses this issue but that'd surely be a good bit of work in its own right. For now, I expect we're better off sticking with the NIST variant since it's public domain. If NIST stops distributing their variant then it might even be better for us to distribute just the *data* (which are identical in the two variants - they differ only in comments). We could do that by removing comments and recalculating the checksum as needed. Although I wouldn't like this solution, that's often the case when lawyers are involved.... [1]: https://datatracker.ietf.org/doc/html/rfc6557#section-7
Paul Eggert via tz:
On 12/9/23 13:30, Tim Parenti wrote:
It still falls short, though. of the ideal that the leap-seconds.list file itself also contain the notice so we (and others) don't have to duplicate it elsewhere: https://mm.icann.org/pipermail/tz/2017-April/024988.html
It also doesn't necessarily allay the other concerns.
Perhaps we could work around the copyright-notice problem by adding appropriate verbiage to the LICENSE file. This would require some thinking, though.
One other problem just occurred to me. Since the IERS variant of leap-seconds.list is not public domain, putting it into tzdata would contradict Internet RFC 6557 section 7 "Data Ownership"[1], which says that tzdata is public domain and therefore is exempt from a bunch of rules that I'm not familiar with and would rather not become expert in if I can avoid it. I suppose this could be worked around by writing a new RFC that addresses this issue but that'd surely be a good bit of work in its own right.
It was me who has asked the folks at IERS some years ago to start providing a leap second file in the format expected by ntpd, and in fact they did, and since that time, an updated file was always available as soon as a new Bulletin C had been published. It was me who asked the folks at IERS a few years ago to start providing a leap second file in the format expected by ntpd, and sure enough they did, and since then an updated file has always been available immediately whenever a new Bulletin C had been published. I remember there has already been a discussion here about the "public domain" requirement shortly after the IERS had started to provide their version of a leap second file. I have been in touch with some people at IERS who are working on this and they have been very cooperative throughout. I'm pretty sure they have no problem making the file "public domain" but the question arises as to what wording should be used to express this in a way that will be accepted by the TZ DB project. Has anyone ever suggested a formulation that meets the requirement of the TZDB project, and told them why this was a requirement? I have no doubt that the folks at IERS would pick it up and integrate it. 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: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
On 2023-12-15 01:31, Martin Burnicki wrote:
I'm pretty sure they have no problem making the file "public domain" but the question arises as to what wording should be used to express this in a way that will be accepted by the TZ DB project. Has anyone ever suggested a formulation that meets the requirement of the TZDB project, and told them why this was a requirement?
Yes, I suggested some wording in an email archived here: https://mm.icann.org/pipermail/tz/2016-February/023214.html The wording was: # COPYRIGHT STATUS OF THIS FILE # This file is in the public domain. and there was some explanation in that email. I vaguely recall corresponding with them directly around then, but don't remember details. It sounds like you have better connections and so perhaps you could forward this email to them. While we're on the topic, a few more suggestions: * It'd be helpful if the file did not contain trailing white space, as that raises some red flags in some text editors and version control systems. * The phrase "see the README file in the 'sources' directory" should be reworded so that the file can stand alone, e.g., by replacing it with the phrase "see <https://hpiers.obspm.fr/iers/bul/bulc/ntp/sources/README>". * The file should suggest the more-secure HTTPS protocol instead of the less-secure FTP protocol. Proposed patch attached (this patch does not recompute the hash code).
On 2023-12-15 11:55, Paul Eggert via tz wrote:
On 2023-12-15 01:31, Martin Burnicki wrote:
I'm pretty sure they have no problem making the file "public domain" but the question arises as to what wording should be used to express this in a way that will be accepted by the TZ DB project. Has anyone ever suggested a formulation that meets the requirement of the TZDB project, and told them why this was a requirement?
Yes, I suggested some wording in an email archived here: https://mm.icann.org/pipermail/tz/2016-February/023214.html The wording was: # COPYRIGHT STATUS OF THIS FILE # This file is in the public domain. and there was some explanation in that email. I vaguely recall corresponding with them directly around then, but don't remember details. It sounds like you have better connections and so perhaps you could forward this email to them. While we're on the topic, a few more suggestions: * It'd be helpful if the file did not contain trailing white space, as that raises some red flags in some text editors and version control systems. * The phrase "see the README file in the 'sources' directory" should be reworded so that the file can stand alone, e.g., by replacing it with the phrase "see <https://hpiers.obspm.fr/iers/bul/bulc/ntp/sources/README>". * The file should suggest the more-secure HTTPS protocol instead of the less-secure FTP protocol. Proposed patch attached (this patch does not recompute the hash code).
The hash code is computed over only the numeric data content comprised of delta TAI offsets and NTP timestamps including those for validity and expiry in flagged comments, so is unchanged. This hash could also do with being upgraded and augmented for backward compatibility by possibly detached sha2/sha3 sum and/or gpg2 signature. My off list comments were made to ObsPM regarding C 50 2015-07 and we all commented on list regarding C 51 2016-01. -- 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
Brian Inglis via tz wrote: [...]
The hash code is computed over only the numeric data content comprised of delta TAI offsets and NTP timestamps including those for validity and expiry in flagged comments, so is unchanged.
This hash could also do with being upgraded and augmented for backward compatibility by possibly detached sha2/sha3 sum and/or gpg2 signature.
IMO the file hash in the existing form is obsolete anyway. At the time when the file format was introduced and the file was downloaded via modem/serial lines, the hash could be used to verify the integrity of the file, but it can't be used to prove the authenticity. Everybody who wants to spoof leap second information can create a file with the desired content and create a valid hash signature for his file. Downloading the file via https instead of FTP increases trustworthiness, but I agree that a gpg2 signature would be very useful to be check the authenticity of the file. On the other hand, the same is true for all data files that are published by IERS and similar institutions. 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: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
Paul Eggert wrote:
On 2023-12-15 01:31, Martin Burnicki wrote:
I'm pretty sure they have no problem making the file "public domain" but the question arises as to what wording should be used to express this in a way that will be accepted by the TZ DB project. Has anyone ever suggested a formulation that meets the requirement of the TZDB project, and told them why this was a requirement?
Yes, I suggested some wording in an email archived here:
I've just sent email to the IERS folks with your proposals, and also some explanations why this is important. So let's see what they reply. 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: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
I've just received a confirmation from the guys at IERS that they will pick up all the suggested changes for the next version of the NTP leap second file that will be published at the beginning of January 2024. So let's see what the next version of the leap second file will look like. Martin Paul Eggert wrote:
On 2023-12-15 01:31, Martin Burnicki wrote:
I'm pretty sure they have no problem making the file "public domain" but the question arises as to what wording should be used to express this in a way that will be accepted by the TZ DB project. Has anyone ever suggested a formulation that meets the requirement of the TZDB project, and told them why this was a requirement?
Yes, I suggested some wording in an email archived here:
https://mm.icann.org/pipermail/tz/2016-February/023214.html
The wording was:
# COPYRIGHT STATUS OF THIS FILE # This file is in the public domain.
and there was some explanation in that email. I vaguely recall corresponding with them directly around then, but don't remember details.
It sounds like you have better connections and so perhaps you could forward this email to them.
While we're on the topic, a few more suggestions:
* It'd be helpful if the file did not contain trailing white space, as that raises some red flags in some text editors and version control systems.
* The phrase "see the README file in the 'sources' directory" should be reworded so that the file can stand alone, e.g., by replacing it with the phrase "see <https://hpiers.obspm.fr/iers/bul/bulc/ntp/sources/README>".
* The file should suggest the more-secure HTTPS protocol instead of the less-secure FTP protocol.
Proposed patch attached (this patch does not recompute the hash code).
-- 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: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
Martin Burnicki via tz wrote in <a3d13ab1-c9be-436b-b960-242ff4c798c1@meinberg.de>: |Paul Eggert via tz: |> On 12/9/23 13:30, Tim Parenti wrote: |>> It still falls short, though. |>> of the ideal that the leap-seconds.list file itself also contain the |>> notice |>> so we (and others) don't have to duplicate it elsewhere: |>> https://mm.icann.org/pipermail/tz/2017-April/024988.html |>> |>> It also doesn't necessarily allay the other concerns. |> |> Perhaps we could work around the copyright-notice problem by adding |> appropriate verbiage to the LICENSE file. This would require some |> thinking, though. |> |> One other problem just occurred to me. Since the IERS variant of |> leap-seconds.list is not public domain, putting it into tzdata would |> contradict Internet RFC 6557 section 7 "Data Ownership"[1], which says ... |I remember there has already been a discussion here about the "public |domain" requirement shortly after the IERS had started to provide their |version of a leap second file. | |I have been in touch with some people at IERS who are working on this |and they have been very cooperative throughout. | |I'm pretty sure they have no problem making the file "public domain" but |the question arises as to what wording should be used to express this in |a way that will be accepted by the TZ DB project. | |Has anyone ever suggested a formulation that meets the requirement of |the TZDB project, and told them why this was a requirement? I have no |doubt that the folks at IERS would pick it up and integrate it. Actually Warner Losh of the FreeBSD project (well, hm, maybe the most authoritative voice, that is), posted on freebsd-stable@ yesterday or two days ago in message CANCZdfrmTZVYD5UDFSLbWvQ2sg-TkG5oeeaqTtVyvsf0PLQNSw@mail.gmail.com | |It's not at all clear there are issues with redistribution. Any files that require a license or purchase are locked down at the web server level. The issues sound more on the FUD end | |of the scale. BIPM has never tried to enforce any ip claims to this file. They have, many years ago, displayed an ignorance of what people want in terms of a clear grant... the bipm, | |or it's subsidiaries, has published all kinds of other data that's clearly more valuable. Leap seconds are a fact that has low to no creative content. It's not even clear you could co | |pyright it... the comments maybe... but I'm not seeing any kind of | |[9]https://ggos.org/terms-of-use/#copyright[/9] | |Text Content | |Text content of the GGOS website is generally under the CC BY-SA license. So you are free to share (copy, redistribute) and modify (remix, transform and rebuild) website materials, |but with the condition to give an appropriate credit (cite GGOS and place a link to the GGOS Website) and if you remix, transform, or rebuilt the material, you must distribute your |contributions under the same license as the original. | | [2] mailto:000.fbsd@quip.cz | [3] https://www.ietf.org/timezones/data/leap-seconds.list | [4] https://www.ietf.org/timezones/data/leap-seconds.list | [5] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list | [6] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list | [7] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275737 | [8] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275737 | [9] https://ggos.org/terms-of-use/#copyright | |IERS is under GGOS organizationally. | |[10]https://ggos.org/item/iers/[/10] absent a different license in the leap seconds file, this seems clear to me. But i am still thinking (unless i missed another commit) that FreeBSD fetches this once and then distributes the copy to all its users. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world. | [Christians might think of Revelation 11:18 | The nations were angry, and your wrath has come[.] | [.]for destroying those who destroy the earth. | But i find the above more kind, and much friendlier]
Steffen Nurpmeso quoted Warner Losh:
The issues sound more on the FUD end of the scale. BIPM has never tried to enforce any ip claims to this file.
People who have been on the receiving end of IP litigation, whether legally defensible or not, tend to take these things rather seriously. ado might be able to provide additional insight on this. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
Doug Ewell wrote in <SJ0PR03MB6598A5AE990D40B4E368913CCA92A@SJ0PR03MB6598.namprd03.prod.outl\ ook.com>: |Steffen Nurpmeso quoted Warner Losh: | |> The issues sound more on the FUD end of the scale. BIPM has never |> tried to enforce any ip claims to this file. | |People who have been on the receiving end of IP litigation, whether \ |legally defensible or not, tend to take these things rather seriously. Sure. Law is a djungle that sees me more like Cheetah not Tarzan. (If i remember that right.) I personally use the ISC license whenever possible, cross my fingers and run away. This is a loosing battle. But he is not only lead of FreeBSD, he is also working for Netflix, which maybe explains some. (I do not watch private TV. Unfortunately the one under public right also declines to below where the BBC never was. Anyhow, this is off-topic.) But .. as i did not follow the links he found .. are they placing the leap seconds file in the public -- or not? |ado might be able to provide additional insight on this. The TZ project is more than a text file with data that is, effectively, available to the public by definition, because it applies to the timekeeping of people. I as a German would for example look for what the PTB says [1], that is an official body of our country. Including DCF77 statement and a link to the secretary, who surely turns off her computer from Friday afternoon to Monday morning, so that the one hour long announcement of a leap second as via während der Stunde vor der Einfügung der Schaltsekunde durch ein Ankündigungsbit (Sekundenmarke Nummer 19) will never be seen be her and her computer. May her NTP client iron over that anomaly. But who am i. [1] https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-441/darstellung-der... The TZ project has intellectual property through code, and maybe also via data collection. (Surely that is, but i am not a lawyer.) This is not true for leap of which politicians and other specialists thing it is not?! Have a nice weekend. Greetings to the Rockies (brrrr!)! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world. | [Christians might think of Revelation 11:18 | The nations were angry, and your wrath has come[.] | [.]for destroying those who destroy the earth. | But i find the above more kind, and much friendlier]
On 2023-12-15 02:31, Martin Burnicki via tz wrote:
Paul Eggert via tz:
On 12/9/23 13:30, Tim Parenti wrote:
It still falls short, though. of the ideal that the leap-seconds.list file itself also contain the notice so we (and others) don't have to duplicate it elsewhere: https://mm.icann.org/pipermail/tz/2017-April/024988.html
It also doesn't necessarily allay the other concerns.
Perhaps we could work around the copyright-notice problem by adding appropriate verbiage to the LICENSE file. This would require some thinking, though.
One other problem just occurred to me. Since the IERS variant of leap-seconds.list is not public domain, putting it into tzdata would contradict Internet RFC 6557 section 7 "Data Ownership"[1], which says that tzdata is public domain and therefore is exempt from a bunch of rules that I'm not familiar with and would rather not become expert in if I can avoid it. I suppose this could be worked around by writing a new RFC that addresses this issue but that'd surely be a good bit of work in its own right.
It was me who has asked the folks at IERS some years ago to start providing a leap second file in the format expected by ntpd, and in fact they did, and since that time, an updated file was always available as soon as a new Bulletin C had been published.
It was me who asked the folks at IERS a few years ago to start providing a leap second file in the format expected by ntpd, and sure enough they did, and since then an updated file has always been available immediately whenever a new Bulletin C had been published.
I remember there has already been a discussion here about the "public domain" requirement shortly after the IERS had started to provide their version of a leap second file.
I have been in touch with some people at IERS who are working on this and they have been very cooperative throughout.
I'm pretty sure they have no problem making the file "public domain" but the question arises as to what wording should be used to express this in a way that will be accepted by the TZ DB project.
Has anyone ever suggested a formulation that meets the requirement of the TZDB project, and told them why this was a requirement? I have no doubt that the folks at IERS would pick it up and integrate it.
I was in touch with them when they initially provided the files, about their often inconsistent validity and expiry dates and timestamps, often expiring before the next Bulletin C would be issued, until they standardized on 0Z on the Bulletin C issue date and the 28th of the last month of the half year following the expected date the next Bulletin C is issued. I also raised the list's concerns resulting in retaining the NIST file, about using or providing copies of the IERS files, with no copyright or licence on the IERS files, lack of EU public domain, its copy, data, and moral rights, and suggested CC-0 or the EU government public data copyright and licence. -- 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
Brian Inglis via tz wrote:
On 2023-12-15 02:31, Martin Burnicki via tz wrote: [...]
Has anyone ever suggested a formulation that meets the requirement of the TZDB project, and told them why this was a requirement? I have no doubt that the folks at IERS would pick it up and integrate it.
I was in touch with them when they initially provided the files, about their often inconsistent validity and expiry dates and timestamps, often expiring before the next Bulletin C would be issued, until they standardized on 0Z on the Bulletin C issue date and the 28th of the last month of the half year following the expected date the next Bulletin C is issued.
Yes, I remember the first publications had some 'glitches', and I had several discussions with the guys. The hardest part was to explain why it is best practice (under the given conditions) to set the expiration date almost 12 months in the future. The problem was that they didn't know how the NTP leap second file is being used. They were assuming that it would be better to let the currently installed file expire, then generate some alarm that the file needed to be updated and then update the file. However, this would mean that the NTP daemon runs for some time without leap second information. BTW, the leap second file is also a good way to provide a device with the TAI/UTC offset, which is important if you run for example a PTP grandmaster. 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: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
On 12/8/2023 3:58 PM, Paul Eggert wrote:
On 2023-12-08 11:58, Brooks Harris via tz wrote:
anything from IERS must be public domain, isn't it? How is it not?
It’s published in France and French law does not recognize the US notion of public domain. The French “domaine public” is more restrictive than the US notion, and as I understand things if published in France the file cannot be domaine public anyway; that can happen only 70 years after publication.
The IERS version lacks a copyright notice, and it’s not clear who holds the copyright or under what terms TZDB could legally reproduce the file. The copyright holder might be the IERS, the Paris Observatory, Paris Sciences et Lettres University, the Ministry of National Education, or some other body. A while ago I asked for a proper copyright notice to be added, to clarify rights and establish permissions, but this has not gotten anywhere presumably because the people in charge of the IERS version are busy and don’t think this is important.
Given the legal uncertainty it’s safer for TZDB to not copy the IERS version. Thanks.
As far as I can tell there is no "leap-seconds.list" file at IERS. This NIST file appears to be a reconstruction of the IERS leap-second data, either assembled from Bulletin C, or transposed from the "Leap_Second_History.dat" file at https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. The NIST file does not appear to explicitly say its in the "public domain". But, as I understand it, anything NIST says, does, or publishes is in "public domain" as far as USA law goes. Hopefully this just remains a matter of my inexpert curiosity.
On 2023-12-08 14:04, Brooks Harris wrote:
As far as I can tell there is no "leap-seconds.list" file at IERS.
It's here: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list as mentioned in 'leapseconds' and 'leapseconds.awk'.
On 12/8/2023 5:07 PM, Paul Eggert wrote:
On 2023-12-08 14:04, Brooks Harris wrote:
As far as I can tell there is no "leap-seconds.list" file at IERS.
It's here:
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
as mentioned in 'leapseconds' and 'leapseconds.awk'. Ah. Thanks. Sure enough. I missed the /ntp/ directory. Interesting. All the comments are entirely different, while the crucial information appears identical. One beauty of leap-seconds is there are so very many versions. :-|
On 2023-12-08 15:04, Brooks Harris via tz wrote:
On 12/8/2023 3:58 PM, Paul Eggert wrote:
On 2023-12-08 11:58, Brooks Harris via tz wrote:
anything from IERS must be public domain, isn't it? How is it not?
It’s published in France and French law does not recognize the US notion of public domain. The French “domaine public” is more restrictive than the US notion, and as I understand things if published in France the file cannot be domaine public anyway; that can happen only 70 years after publication.
The IERS version lacks a copyright notice, and it’s not clear who holds the copyright or under what terms TZDB could legally reproduce the file. The copyright holder might be the IERS, the Paris Observatory, Paris Sciences et Lettres University, the Ministry of National Education, or some other body. A while ago I asked for a proper copyright notice to be added, to clarify rights and establish permissions, but this has not gotten anywhere presumably because the people in charge of the IERS version are busy and don’t think this is important.
Given the legal uncertainty it’s safer for TZDB to not copy the IERS version. Thanks.
As far as I can tell there is no "leap-seconds.list" file at IERS. This NIST file appears to be a reconstruction of the IERS leap-second data, either assembled from Bulletin C, or transposed from the "Leap_Second_History.dat" file at https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat.
On most leap seconds sites, leap-seconds.list is usually a symlink to leap-seconds.NTPTIME, where NTPTIME is usually the integer NTP time stamp at 0Z on the date of the most recent bulletin C, or the local issue date e.g. $ curl ftp://hpiers.obspm.fr/iers/bul/bulc/ntp/ -rw-rw-r-- 1 ftp ftp 540 Jul 06 2016 README -rw-rw-r-- 1 ftp ftp 4928 Apr 03 2015 leap-seconds.3637008000 -rw-rw-r-- 1 ftp ftp 4928 Jul 07 2015 leap-seconds.3645216000 -rw-rw-r-- 1 ftp ftp 4927 Sep 16 2015 leap-seconds.3651350400 -rw-rw-r-- 1 ftp ftp 4928 Jan 11 2016 leap-seconds.3661459200 -rw-rw-r-- 1 ftp ftp 4928 Jan 13 2016 leap-seconds.3661632000 -rw-rw-r-- 1 ftp ftp 4920 Jul 06 2016 leap-seconds.3676752000 -rw-rw-r-- 1 ftp ftp 4925 Jan 19 2017 leap-seconds.3693772800 -rw-r--r-- 1 ftp ftp 4921 Jul 07 2017 leap-seconds.3708374400 -rw-r--r-- 1 ftp ftp 4923 Jan 09 2018 leap-seconds.3724483581 -rw-r--r-- 1 ftp ftp 4921 Jul 05 2018 leap-seconds.3739787886 -rw-r--r-- 1 ftp ftp 4949 Jul 04 2019 leap-seconds.3771235866 -rw-r--r-- 1 ftp ftp 4953 Jan 07 2020 leap-seconds.3787382231 -rw-r--r-- 1 ftp ftp 4949 Jul 07 2020 leap-seconds.3803144275 -rw-r--r-- 1 ftp ftp 4953 Jan 07 2021 leap-seconds.3819011916 -rw-r--r-- 1 ftp ftp 4949 Jul 05 2021 leap-seconds.3834432000 -rw-r--r-- 1 ftp ftp 4953 Jan 05 2022 leap-seconds.3850377469 -rw-r--r-- 1 ftp ftp 4949 Jul 05 2022 leap-seconds.3865995417 -rw-r--r-- 1 ftp ftp 4953 Jan 09 2023 leap-seconds.3882249427 -rw-r--r-- 1 ftp ftp 4949 Jul 04 13:06 leap-seconds.3897417600 lrwxrwxrwx 1 ftp ftp 23 Jul 04 13:06 leap-seconds.list -> leap-seconds.3897417600 drwxr-xr-x 2 ftp ftp 4096 Apr 03 2015 sources Also https://hpiers.obspm.fr/iers/bul/bulc/ntp/?C=M;O=D and the other Bulletin C data: https://hpiers.obspm.fr/iers/bul/bulc/?C=M;O=D
The NIST file does not appear to explicitly say its in the "public domain". But, as I understand it, anything NIST says, does, or publishes is in "public domain" as far as USA law goes. Hopefully this just remains a matter of my inexpert curiosity.
Other referring documents remind users that most documents and data on sites are in the public domain in the US: https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-da... -- 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 12/9/2023 3:47 PM, Brian Inglis via tz wrote:
On 2023-12-08 15:04, Brooks Harris via tz wrote:
On 12/8/2023 3:58 PM, Paul Eggert wrote:
On 2023-12-08 11:58, Brooks Harris via tz wrote:
anything from IERS must be public domain, isn't it? How is it not?
It’s published in France and French law does not recognize the US notion of public domain. The French “domaine public” is more restrictive than the US notion, and as I understand things if published in France the file cannot be domaine public anyway; that can happen only 70 years after publication.
The IERS version lacks a copyright notice, and it’s not clear who holds the copyright or under what terms TZDB could legally reproduce the file. The copyright holder might be the IERS, the Paris Observatory, Paris Sciences et Lettres University, the Ministry of National Education, or some other body. A while ago I asked for a proper copyright notice to be added, to clarify rights and establish permissions, but this has not gotten anywhere presumably because the people in charge of the IERS version are busy and don’t think this is important.
Given the legal uncertainty it’s safer for TZDB to not copy the IERS version. Thanks.
As far as I can tell there is no "leap-seconds.list" file at IERS. This NIST file appears to be a reconstruction of the IERS leap-second data, either assembled from Bulletin C, or transposed from the "Leap_Second_History.dat" file at https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat.
On most leap seconds sites, leap-seconds.list is usually a symlink to leap-seconds.NTPTIME, where NTPTIME is usually the integer NTP time stamp at 0Z on the date of the most recent bulletin C, or the local issue date e.g.
$ curl ftp://hpiers.obspm.fr/iers/bul/bulc/ntp/ -rw-rw-r-- 1 ftp ftp 540 Jul 06 2016 README -rw-rw-r-- 1 ftp ftp 4928 Apr 03 2015 leap-seconds.3637008000 -rw-rw-r-- 1 ftp ftp 4928 Jul 07 2015 leap-seconds.3645216000 -rw-rw-r-- 1 ftp ftp 4927 Sep 16 2015 leap-seconds.3651350400 -rw-rw-r-- 1 ftp ftp 4928 Jan 11 2016 leap-seconds.3661459200 -rw-rw-r-- 1 ftp ftp 4928 Jan 13 2016 leap-seconds.3661632000 -rw-rw-r-- 1 ftp ftp 4920 Jul 06 2016 leap-seconds.3676752000 -rw-rw-r-- 1 ftp ftp 4925 Jan 19 2017 leap-seconds.3693772800 -rw-r--r-- 1 ftp ftp 4921 Jul 07 2017 leap-seconds.3708374400 -rw-r--r-- 1 ftp ftp 4923 Jan 09 2018 leap-seconds.3724483581 -rw-r--r-- 1 ftp ftp 4921 Jul 05 2018 leap-seconds.3739787886 -rw-r--r-- 1 ftp ftp 4949 Jul 04 2019 leap-seconds.3771235866 -rw-r--r-- 1 ftp ftp 4953 Jan 07 2020 leap-seconds.3787382231 -rw-r--r-- 1 ftp ftp 4949 Jul 07 2020 leap-seconds.3803144275 -rw-r--r-- 1 ftp ftp 4953 Jan 07 2021 leap-seconds.3819011916 -rw-r--r-- 1 ftp ftp 4949 Jul 05 2021 leap-seconds.3834432000 -rw-r--r-- 1 ftp ftp 4953 Jan 05 2022 leap-seconds.3850377469 -rw-r--r-- 1 ftp ftp 4949 Jul 05 2022 leap-seconds.3865995417 -rw-r--r-- 1 ftp ftp 4953 Jan 09 2023 leap-seconds.3882249427 -rw-r--r-- 1 ftp ftp 4949 Jul 04 13:06 leap-seconds.3897417600 lrwxrwxrwx 1 ftp ftp 23 Jul 04 13:06 leap-seconds.list -> leap-seconds.3897417600 drwxr-xr-x 2 ftp ftp 4096 Apr 03 2015 sources
Also https://hpiers.obspm.fr/iers/bul/bulc/ntp/?C=M;O=D
and the other Bulletin C data:
https://hpiers.obspm.fr/iers/bul/bulc/?C=M;O=D
The NIST file does not appear to explicitly say its in the "public domain". But, as I understand it, anything NIST says, does, or publishes is in "public domain" as far as USA law goes. Hopefully this just remains a matter of my inexpert curiosity.
Other referring documents remind users that most documents and data on sites are in the public domain in the US:
https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-da...
Thanks for this link. That answers a lot of my questions. By the way, notice the "Standards" icon at bottom of that page. It leads to really good explanations of NIST standards topics, including: UTC(NIST) Time Scale https://www.nist.gov/pml/time-and-frequency-division/time-realization/utcnis...
On 2023-12-08 12:58, Brooks Harris via tz wrote:
On 12/7/2023 9:29 PM, Paul Eggert via tz wrote:
On 12/7/23 13:21, Geert Hendrickx wrote:
NTPsec logs the following at startup:
CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): good hash signature
CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): loaded, expire=2024-06-28T00:00Z last=2017-01-01T00:00Z ofs=37
So I *guess* (without having looked at the code) that it actually cares about the expiration date as well.
I think you're right NTPsec does care, though I vaguely recall that if the file has expired the only issue is an unwanted log message.
If people are running NTPsec and configuring it to use TZDB's leap-seconds.list, that unwanted log message could be an issue. I just now checked the NTPsec source code, though, and by default it uses this URL:
https://www.ietf.org/timezones/data/leap-seconds.list
which hasn't worked in a while; the contents are simply "ietf.org is no longer serving this file." So it may be that we don't need to issue a new TZDB release merely because 2023c's leap-seconds.list will be out-of-date soon.
(but we periodically download it from IERS, not from TZ)
In that case your setup is OK as-is, though we may still need to hear from other people to see whether they're relying on the TZDB copy of leap-seconds.list.
TZDB uses the NIST version of leap-seconds.list rather than the IERS version, as the NIST version is clearly public domain and so this way we don't have to worry about copyright issues. However, the IERS version should work fine with either NTPsec or with other downstream uses, such as TZDB itself (that is, if you're not worried about copyright).
In my opinion TzDb should update the leap-seconds.list date and issue a TzDb release because there's no telling who might be using it and perhaps relying on the expiry date.
The current expiry date at https://ftp.iana.org/tz/tzdb-2023c/leap-seconds.list is # File expires on: 28 December 2023
The current expiry date at ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list is # File expires on: 28 June 2024
There are other sources at IERS besides Bulletin C. In my development work I've been using: https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat
This file has a different form, using MJD rather than "number of seconds since 1 January 1900, 00:00:00".
Note that, as I understand it, Bulletin C is the only official "product" of the IERS. But this Leap_Second_History.dat file has been being issued and maintained for years.
I cannot comment expertly on "copyright", but it seems to me anything from IERS must be public domain, isn't it? How is it not?
FR and many EU countries are on the Napoleonic era Civil Code which does not recognize the public domain and asserts copyrights and many personal and moral rights over documents and data and database rights over data and compilations; I believe that may also be substantially true in the English common law UK (although the KJV Bible rights are held in perpetuity by the Crown, and "Peter Pan" was granted in perpetuity to Great Ormond Street Childrens' Hospital, although expiring in the US this month): https://www.burnesspaull.com/insights-and-events/news/copyright-and-the-publ... in some South American and African countries breach of copyright and other rights may be in the Criminal Code, payments for works including cultural, traditional, and public domain works may be required, may be perpetual, may be payable to governments rather than creators, and may require no authorization! How this applies to foreign works is idiosyncratic: in some countries it is possible that a tax^Wroyalty is payable for use of the tzdb. -- 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
participants (9)
-
Brian Inglis -
Brian.Inglis＠shaw.ca
-
Brooks Harris -
Doug Ewell -
Martin Burnicki -
Paul Eggert -
Steffen Nurpmeso -
Steve Allen -
Tim Parenti