time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

On the IETF leap-seconds.list SHA1

AW
Anders Wallin
Wed, Dec 20, 2017 11:51 AM

Hi all,
So I'm doing the typical Wednesday thing you might do, that is writing a
small script for checking the SHA1 checksum in leap-seconds.list files.
I came up with [1] which produces output [2].

For the Paris Observatory and USNO files my program agrees with the SHA1s
in the files.
For the IETF file there seems to be one byte, a "0" at the start of the
third group of 8 hex characters missing.

This is somewhat funny/alarming, since the IETF leap-seconds.list is the
first thing that shows up (at least for me) on google when looking for
leap-seocnds.list.

Please do add to and improve on my code on github - if this is your sort of
thing ;)

happy holidays!
Anders

[1]
https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/leap_sha.py
[2]
https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/output.txt

Hi all, So I'm doing the typical Wednesday thing you might do, that is writing a small script for checking the SHA1 checksum in leap-seconds.list files. I came up with [1] which produces output [2]. For the Paris Observatory and USNO files my program agrees with the SHA1s in the files. For the IETF file there seems to be one byte, a "0" at the start of the third group of 8 hex characters missing. This is somewhat funny/alarming, since the IETF leap-seconds.list is the first thing that shows up (at least for me) on google when looking for leap-seocnds.list. Please do add to and improve on my code on github - if this is your sort of thing ;) happy holidays! Anders [1] https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/leap_sha.py [2] https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/output.txt
JH
John Hawkinson
Wed, Dec 20, 2017 12:18 PM

Umm, the presence of a copy of the IANA TZ distribution at https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds list." This is bizarre, and probably a web server configuration error that even exists. The IETF is not involved in this list. I guess this shows why Google is an unreliable indicator of authority.

https://www.ietf.org/timezones/data/leap-seconds.list
is not a URL anyone should be depending on.

https://data.iana.org/time-zones/code/leap-seconds.list
is perhaps a better URL for the file in the tz distribution, but I'd hestitate to call it canonical. Start at https://www.iana.org/time-zones.

But then the tz database isn't an authorative source, either. Per the NEWS file:

The 'leapseconds' file is now generated automatically from a
new file 'leap-seconds.list', which is a copy of
<ftp://time.nist.gov/pub/leap-seconds.list>.
A new source file 'leapseconds.awk' implements this.
The goal is simplification of the future maintenance of 'leapseconds'.

That is, it's just a copy of NIST's file.

Your email would make a lot more sense if you had included the URLs directly rather than referring to your source code and output file that happen to contain them.

--jhawk@mit.edu
John Hawkinson

Anders Wallin anders.e.e.wallin@gmail.com wrote on Wed, 20 Dec 2017
at 13:51:21 +0200 in CAPnVNRV=4gxKn5C3-Zh6zfqwK6NhjNcn9Qkr_rLhU-GkfzYZHQ@mail.gmail.com:

So I'm doing the typical Wednesday thing you might do, that is writing a
small script for checking the SHA1 checksum in leap-seconds.list files.
I came up with [1] which produces output [2].

...

For the IETF file there seems to be one byte, a "0" at the start of the
third group of 8 hex characters missing.

This is somewhat funny/alarming, since the IETF leap-seconds.list is the
first thing that shows up (at least for me) on google when looking for
leap-seocnds.list.

...

Umm, the presence of a copy of the IANA TZ distribution at https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds list." This is bizarre, and probably a web server configuration error that even exists. The IETF is not involved in this list. I guess this shows why Google is an unreliable indicator of authority. https://www.ietf.org/timezones/data/leap-seconds.list is not a URL anyone should be depending on. https://data.iana.org/time-zones/code/leap-seconds.list is perhaps a better URL for the file in the tz distribution, but I'd hestitate to call it canonical. Start at https://www.iana.org/time-zones. But then the tz database isn't an authorative source, either. Per the NEWS file: The 'leapseconds' file is now generated automatically from a new file 'leap-seconds.list', which is a copy of <ftp://time.nist.gov/pub/leap-seconds.list>. A new source file 'leapseconds.awk' implements this. The goal is simplification of the future maintenance of 'leapseconds'. That is, it's just a copy of NIST's file. Your email would make a lot more sense if you had included the URLs directly rather than referring to your source code and output file that happen to contain them. --jhawk@mit.edu John Hawkinson Anders Wallin <anders.e.e.wallin@gmail.com> wrote on Wed, 20 Dec 2017 at 13:51:21 +0200 in <CAPnVNRV=4gxKn5C3-Zh6zfqwK6NhjNcn9Qkr_rLhU-GkfzYZHQ@mail.gmail.com>: > So I'm doing the typical Wednesday thing you might do, that is writing a > small script for checking the SHA1 checksum in leap-seconds.list files. > I came up with [1] which produces output [2]. ... > For the IETF file there seems to be one byte, a "0" at the start of the > third group of 8 hex characters missing. > > This is somewhat funny/alarming, since the IETF leap-seconds.list is the > first thing that shows up (at least for me) on google when looking for > leap-seocnds.list. ... > [1] > https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/leap_sha.py > [2] > https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/output.txt
AW
Anders Wallin
Wed, Dec 20, 2017 1:46 PM

Thanks,
I added the IANA URL to my list, and sent them an e-mail.
I can't seem to reach the nist ftp-server - does it work for anyone?

I re-named the output.txt so the link in my previous e-mail won't work.
The output now shows on the github repo frontpage:
https://github.com/aewallin/leap-seconds.list_sha1_check

Anders

On Wed, Dec 20, 2017 at 2:18 PM, John Hawkinson jhawk@mit.edu wrote:

Umm, the presence of a copy of the IANA TZ distribution at
https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds
list." This is bizarre, and probably a web server configuration error that
even exists. The IETF is not involved in this list. I guess this shows why
Google is an unreliable indicator of authority.

https://www.ietf.org/timezones/data/leap-seconds.list
is not a URL anyone should be depending on.

https://data.iana.org/time-zones/code/leap-seconds.list
is perhaps a better URL for the file in the tz distribution, but I'd
hestitate to call it canonical. Start at https://www.iana.org/time-zones.

But then the tz database isn't an authorative source, either. Per the NEWS
file:

 The 'leapseconds' file is now generated automatically from a
 new file 'leap-seconds.list', which is a copy of
 <ftp://time.nist.gov/pub/leap-seconds.list>.
 A new source file 'leapseconds.awk' implements this.
 The goal is simplification of the future maintenance of 'leapseconds'.

That is, it's just a copy of NIST's file.

Your email would make a lot more sense if you had included the URLs
directly rather than referring to your source code and output file that
happen to contain them.

--jhawk@mit.edu
John Hawkinson

Anders Wallin anders.e.e.wallin@gmail.com wrote on Wed, 20 Dec 2017
at 13:51:21 +0200 in <CAPnVNRV=4gxKn5C3-Zh6zfqwK6NhjNcn9Qkr_rLhU-
GkfzYZHQ@mail.gmail.com>:

So I'm doing the typical Wednesday thing you might do, that is writing a
small script for checking the SHA1 checksum in leap-seconds.list files.
I came up with [1] which produces output [2].

...

For the IETF file there seems to be one byte, a "0" at the start of the
third group of 8 hex characters missing.

This is somewhat funny/alarming, since the IETF leap-seconds.list is the
first thing that shows up (at least for me) on google when looking for
leap-seocnds.list.

...

blob/master/leap_sha.py

blob/master/output.txt


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

Thanks, I added the IANA URL to my list, and sent them an e-mail. I can't seem to reach the nist ftp-server - does it work for anyone? I re-named the output.txt so the link in my previous e-mail won't work. The output now shows on the github repo frontpage: https://github.com/aewallin/leap-seconds.list_sha1_check Anders On Wed, Dec 20, 2017 at 2:18 PM, John Hawkinson <jhawk@mit.edu> wrote: > Umm, the presence of a copy of the IANA TZ distribution at > https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds > list." This is bizarre, and probably a web server configuration error that > even exists. The IETF is not involved in this list. I guess this shows why > Google is an unreliable indicator of authority. > > https://www.ietf.org/timezones/data/leap-seconds.list > is not a URL anyone should be depending on. > > https://data.iana.org/time-zones/code/leap-seconds.list > is perhaps a better URL for the file in the tz distribution, but I'd > hestitate to call it canonical. Start at https://www.iana.org/time-zones. > > But then the tz database isn't an authorative source, either. Per the NEWS > file: > > The 'leapseconds' file is now generated automatically from a > new file 'leap-seconds.list', which is a copy of > <ftp://time.nist.gov/pub/leap-seconds.list>. > A new source file 'leapseconds.awk' implements this. > The goal is simplification of the future maintenance of 'leapseconds'. > > That is, it's just a copy of NIST's file. > > Your email would make a lot more sense if you had included the URLs > directly rather than referring to your source code and output file that > happen to contain them. > > --jhawk@mit.edu > John Hawkinson > > Anders Wallin <anders.e.e.wallin@gmail.com> wrote on Wed, 20 Dec 2017 > at 13:51:21 +0200 in <CAPnVNRV=4gxKn5C3-Zh6zfqwK6NhjNcn9Qkr_rLhU- > GkfzYZHQ@mail.gmail.com>: > > > > So I'm doing the typical Wednesday thing you might do, that is writing a > > small script for checking the SHA1 checksum in leap-seconds.list files. > > I came up with [1] which produces output [2]. > ... > > For the IETF file there seems to be one byte, a "0" at the start of the > > third group of 8 hex characters missing. > > > > This is somewhat funny/alarming, since the IETF leap-seconds.list is the > > first thing that shows up (at least for me) on google when looking for > > leap-seocnds.list. > ... > > > [1] > > https://github.com/aewallin/leap-seconds.list_sha1_check/ > blob/master/leap_sha.py > > [2] > > https://github.com/aewallin/leap-seconds.list_sha1_check/ > blob/master/output.txt > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >
MB
Martin Burnicki
Wed, Dec 20, 2017 1:50 PM

John Hawkinson wrote:

Umm, the presence of a copy of the IANA TZ distribution at https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds list." This is bizarre, and probably a web server configuration error that even exists. The IETF is not involved in this list. I guess this shows why Google is an unreliable indicator of authority.

https://www.ietf.org/timezones/data/leap-seconds.list
is not a URL anyone should be depending on.

https://data.iana.org/time-zones/code/leap-seconds.list
is perhaps a better URL for the file in the tz distribution, but I'd hestitate to call it canonical. Start at https://www.iana.org/time-zones.

But then the tz database isn't an authorative source, either. Per the NEWS file:

 The 'leapseconds' file is now generated automatically from a
 new file 'leap-seconds.list', which is a copy of
 <ftp://time.nist.gov/pub/leap-seconds.list>.
 A new source file 'leapseconds.awk' implements this.
 The goal is simplification of the future maintenance of 'leapseconds'.

That is, it's just a copy of NIST's file.

In fact, when NIST or IERS have provided a new leap-seconds.list file
then it is picked up somewhat later by the TZ database maintainers, and
updated in the TZ database.

The IERS page only provides the content of the last recently released TZ
database package, so the updated leap-seconds.list file will only appear
on the IERS page after a new version of the TZ database has been
released, whenever that happens.

So there may be a significant delay until an updated leap-seconds.list
file becomes available at the IETF web site, and I strongly suggest to
pick that file up from either
ftp://time.nist.gov/pub/leap-seconds.list

or
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

See also a summary at
https://www.meinbergglobal.com/download/burnicki/the_ntp_leap_second_file.pdf

Martin

John Hawkinson wrote: > Umm, the presence of a copy of the IANA TZ distribution at https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds list." This is bizarre, and probably a web server configuration error that even exists. The IETF is not involved in this list. I guess this shows why Google is an unreliable indicator of authority. > > https://www.ietf.org/timezones/data/leap-seconds.list > is not a URL anyone should be depending on. > > https://data.iana.org/time-zones/code/leap-seconds.list > is perhaps a better URL for the file in the tz distribution, but I'd hestitate to call it canonical. Start at https://www.iana.org/time-zones. > > But then the tz database isn't an authorative source, either. Per the NEWS file: > > The 'leapseconds' file is now generated automatically from a > new file 'leap-seconds.list', which is a copy of > <ftp://time.nist.gov/pub/leap-seconds.list>. > A new source file 'leapseconds.awk' implements this. > The goal is simplification of the future maintenance of 'leapseconds'. > > That is, it's just a copy of NIST's file. In fact, when NIST or IERS have provided a new leap-seconds.list file then it is picked up somewhat later by the TZ database maintainers, and updated in the TZ database. The IERS page only provides the content of the last recently released TZ database package, so the updated leap-seconds.list file will only appear on the IERS page after a new version of the TZ database has been released, whenever that happens. So there may be a significant delay until an updated leap-seconds.list file becomes available at the IETF web site, and I strongly suggest to pick that file up from either ftp://time.nist.gov/pub/leap-seconds.list or https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list See also a summary at https://www.meinbergglobal.com/download/burnicki/the_ntp_leap_second_file.pdf Martin
MB
Martin Burnicki
Wed, Dec 20, 2017 1:53 PM

Anders Wallin wrote:

Thanks,
I added the IANA URL to my list, and sent them an e-mail.
I can't seem to reach the nist ftp-server - does it work for anyone?

Please note the global address time.nist.gov is resolved to a number of
public servers in a round-robin sequence. Some of the servers may not be
reachable due to a high load, and others might resolve to IPv6 addresses
and thus can only be reached if there is a direct IPv6 or IPv6-over-IPv4
tunnel to the internet.

According to an email from Judah Levine (NIST) the current version of
the leap second file is available via anonymous FTP from all public NIST
NTP servers. A list of these servers and the status of each server is
available at
http://tf.nist.gov/tf-cgi/servers.cgi

which is linked to from
http://tf.nist.gov/

See also the PDF I mentioned in the email I just sent a minute ago.

Martin

Anders Wallin wrote: > Thanks, > I added the IANA URL to my list, and sent them an e-mail. > I can't seem to reach the nist ftp-server - does it work for anyone? Please note the global address time.nist.gov is resolved to a number of public servers in a round-robin sequence. Some of the servers may not be reachable due to a high load, and others might resolve to IPv6 addresses and thus can only be reached if there is a direct IPv6 or IPv6-over-IPv4 tunnel to the internet. According to an email from Judah Levine (NIST) the current version of the leap second file is available via anonymous FTP from all public NIST NTP servers. A list of these servers and the status of each server is available at http://tf.nist.gov/tf-cgi/servers.cgi which is linked to from http://tf.nist.gov/ See also the PDF I mentioned in the email I just sent a minute ago. Martin
MB
Martin Burnicki
Wed, Dec 20, 2017 2:19 PM

Martin Burnicki wrote:

According to an email from Judah Levine (NIST) the current version of
the leap second file is available via anonymous FTP from all public NIST
NTP servers. A list of these servers and the status of each server is
available at
http://tf.nist.gov/tf-cgi/servers.cgi

which is linked to from
http://tf.nist.gov/

Martin Burnicki wrote: > According to an email from Judah Levine (NIST) the current version of > the leap second file is available via anonymous FTP from all public NIST > NTP servers. A list of these servers and the status of each server is > available at > http://tf.nist.gov/tf-cgi/servers.cgi > > which is linked to from > http://tf.nist.gov/ I just saw that the main page http://tf.nist.gov/ has moved. It's now https://www.nist.gov/pml/time-and-frequency-division or https://www.nist.gov/pml/time-and-frequency-division/services/internet-time-service-its Martin
MB
Martin Burnicki
Wed, Dec 20, 2017 4:13 PM

Martin Burnicki wrote:

I saw that the leapseconds file provided by USNO is outdated, and FTP
access to the NIST sites has changed, so I've just updated the PDF
accordingly.

Martin

Martin Burnicki wrote: > See also a summary at > https://www.meinbergglobal.com/download/burnicki/the_ntp_leap_second_file.pdf I saw that the leapseconds file provided by USNO is outdated, and FTP access to the NIST sites has changed, so I've just updated the PDF accordingly. Martin
MC
Mike Cook
Wed, Dec 20, 2017 4:52 PM

Le 20 déc. 2017 à 12:51, Anders Wallin anders.e.e.wallin@gmail.com a écrit :

Hi all,
So I'm doing the typical Wednesday thing you might do, that is writing a
small script for checking the SHA1 checksum in leap-seconds.list files.
I came up with [1] which produces output [2].

For the Paris Observatory and USNO files my program agrees with the SHA1s
in the files.
For the IETF file there seems to be one byte, a "0" at the start of the
third group of 8 hex characters missing.

This is somewhat funny/alarming, since the IETF leap-seconds.list is the
first thing that shows up (at least for me) on google when looking for
leap-seocnds.list.

This is not a bug but a « feature ». From the ntpd leap hash checking code:

  • The NIST code creating the hash writes them out as 5 hex integers

  • without leading zeros.

    Still, it a little unorthodox and complicates the code.

Please do add to and improve on my code on github - if this is your sort of
thing ;)

happy holidays!
Anders

[1]
https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/leap_sha.py
[2]
https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/output.txt


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw

> Le 20 déc. 2017 à 12:51, Anders Wallin <anders.e.e.wallin@gmail.com> a écrit : > > Hi all, > So I'm doing the typical Wednesday thing you might do, that is writing a > small script for checking the SHA1 checksum in leap-seconds.list files. > I came up with [1] which produces output [2]. > > For the Paris Observatory and USNO files my program agrees with the SHA1s > in the files. > For the IETF file there seems to be one byte, a "0" at the start of the > third group of 8 hex characters missing. > > This is somewhat funny/alarming, since the IETF leap-seconds.list is the > first thing that shows up (at least for me) on google when looking for > leap-seocnds.list. This is not a bug but a « feature ». From the ntpd leap hash checking code: * The NIST code creating the hash writes them out as 5 hex integers * without leading zeros. Still, it a little unorthodox and complicates the code. > > Please do add to and improve on my code on github - if this is your sort of > thing ;) > > happy holidays! > Anders > > [1] > https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/leap_sha.py > [2] > https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/output.txt > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw
AW
Anders Wallin
Thu, Dec 21, 2017 6:01 AM

For the Paris Observatory and USNO files my program agrees with the SHA1s
in the files.
For the IETF file there seems to be one byte, a "0" at the start of the
third group of 8 hex characters missing.

This is not a bug but a « feature ». From the ntpd leap hash checking

code:

  • The NIST code creating the hash writes them out as 5 hex integers

  • without leading zeros.

    Still, it a little unorthodox and complicates the code.

Ha! Thanks for explaining this.
Indeed I find writing out the SHA-1 in groups of 8 characters without
leading zeroes quite surprising and undocumented.
The comments in leap-seconds.list about the SHA-1 refer to a /sha or
/pub/sha folder - is that generic information on the SHA-1 or is there any
inidication of the 8-char/leading-zeroes convention there?
I quickly looked at FIPS-180 but didn't find anything about leading zeros
there.

I am still unable to access the NIST ftp-site linked earlier in this thread.

Anders

> > > For the Paris Observatory and USNO files my program agrees with the SHA1s > > in the files. > > For the IETF file there seems to be one byte, a "0" at the start of the > > third group of 8 hex characters missing. > > This is not a bug but a « feature ». From the ntpd leap hash checking > code: > > * The NIST code creating the hash writes them out as 5 hex integers > * without leading zeros. > > Still, it a little unorthodox and complicates the code. > Ha! Thanks for explaining this. Indeed I find writing out the SHA-1 in groups of 8 characters without leading zeroes quite surprising and undocumented. The comments in leap-seconds.list about the SHA-1 refer to a /sha or /pub/sha folder - is that generic information on the SHA-1 or is there any inidication of the 8-char/leading-zeroes convention there? I quickly looked at FIPS-180 but didn't find anything about leading zeros there. I am still unable to access the NIST ftp-site linked earlier in this thread. Anders
MC
Mike Cook
Thu, Dec 21, 2017 8:08 AM

Le 21 déc. 2017 à 07:01, Anders Wallin anders.e.e.wallin@gmail.com a écrit :

For the Paris Observatory and USNO files my program agrees with the SHA1s
in the files.
For the IETF file there seems to be one byte, a "0" at the start of the
third group of 8 hex characters missing.

This is not a bug but a « feature ». From the ntpd leap hash checking
code:

  • The NIST code creating the hash writes them out as 5 hex integers

  • without leading zeros.

    Still, it a little unorthodox and complicates the code.

Ha! Thanks for explaining this.
Indeed I find writing out the SHA-1 in groups of 8 characters without
leading zeroes quite surprising and undocumented.
The comments in leap-seconds.list about the SHA-1 refer to a /sha or
/pub/sha folder - is that generic information on the SHA-1 or is there any
inidication of the 8-char/leading-zeroes convention there?
I quickly looked at FIPS-180 but didn't find anything about leading zeros
there.

My guess is that during testing the NIST guy who created the program to print the list never hit the case where the integer created a less than 8 character hex output.
Probably used %8x instead of %08x in his format statement, or something analog if it was not C.  A case of «  economy of thought » .

I am still unable to access the NIST ftp-site linked earlier in this thread.

Anders


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw

> Le 21 déc. 2017 à 07:01, Anders Wallin <anders.e.e.wallin@gmail.com> a écrit : > >> >>> For the Paris Observatory and USNO files my program agrees with the SHA1s >>> in the files. >>> For the IETF file there seems to be one byte, a "0" at the start of the >>> third group of 8 hex characters missing. >> >> This is not a bug but a « feature ». From the ntpd leap hash checking >> code: >> >> * The NIST code creating the hash writes them out as 5 hex integers >> * without leading zeros. >> >> Still, it a little unorthodox and complicates the code. >> > > Ha! Thanks for explaining this. > Indeed I find writing out the SHA-1 in groups of 8 characters without > leading zeroes quite surprising and undocumented. > The comments in leap-seconds.list about the SHA-1 refer to a /sha or > /pub/sha folder - is that generic information on the SHA-1 or is there any > inidication of the 8-char/leading-zeroes convention there? > I quickly looked at FIPS-180 but didn't find anything about leading zeros > there. My guess is that during testing the NIST guy who created the program to print the list never hit the case where the integer created a less than 8 character hex output. Probably used %8x instead of %08x in his format statement, or something analog if it was not C. A case of « economy of thought » . > > I am still unable to access the NIST ftp-site linked earlier in this thread. > > Anders > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw