On 2015-01-06 21:22, Tim Parenti wrote:
+# Some systems implement leap seconds by amortizing the leap second +# over the last few minutes of the day. The frequency of the local +# clock is decreased (or increased) to realize the positive (or +# negative) leap second. This method removes the time step described +# above. Although the long-term behavior of the time scale is correct +# in this case, this method introduces an error during the adjustment +# period both in time and in frequency with respect to the official +# defintion of UTC.
s/defintion/definition/ Regards, Denis Excoffier.
Denis, This error was present in the leap-seconds.3629404800 file as provided by NIST. I have copied Judah Levine on this message so that it might be fixed in their next version. On 7 January 2015 at 16:15, Denis Excoffier <iana@denis-excoffier.org> wrote:
On 2015-01-06 21:22, Tim Parenti wrote:
+# Some systems implement leap seconds by amortizing the leap second +# over the last few minutes of the day. The frequency of the local +# clock is decreased (or increased) to realize the positive (or +# negative) leap second. This method removes the time step described +# above. Although the long-term behavior of the time scale is correct +# in this case, this method introduces an error during the adjustment +# period both in time and in frequency with respect to the official +# defintion of UTC.
s/defintion/definition/
Regards,
Denis Excoffier.
-- Tim Parenti
For now it can be changed to "official defin[i]tion of UTC" or "official [definition] of UTC" in the TZDB copy. (I'd go with the first; the second causes less spell checker grief.) @dashdashado On Wed, Jan 7, 2015 at 4:19 PM, Tim Parenti <tim@timtimeonline.com> wrote:
Denis,
This error was present in the leap-seconds.3629404800 file as provided by NIST. I have copied Judah Levine on this message so that it might be fixed in their next version.
On 7 January 2015 at 16:15, Denis Excoffier <iana@denis-excoffier.org> wrote:
On 2015-01-06 21:22, Tim Parenti wrote:
+# Some systems implement leap seconds by amortizing the leap second +# over the last few minutes of the day. The frequency of the local +# clock is decreased (or increased) to realize the positive (or +# negative) leap second. This method removes the time step described +# above. Although the long-term behavior of the time scale is correct +# in this case, this method introduces an error during the adjustment +# period both in time and in frequency with respect to the official +# defintion of UTC.
s/defintion/definition/
Regards,
Denis Excoffier.
-- Tim Parenti
Hello, Thanks for the note about the typo. It is in a comment line and has no effect on the data. It is a significant job to make and document the change and to push it out to all of our servers, so I probably won't correct the error for now. Best wishes, Judah Levine Time and Frequency Division NIST Boulder Sent from my iPad On Jan 7, 2015, at 2:19 PM, "Tim Parenti" <tim@timtimeonline.com<mailto:tim@timtimeonline.com>> wrote: Denis, This error was present in the leap-seconds.3629404800 file as provided by NIST. I have copied Judah Levine on this message so that it might be fixed in their next version. On 7 January 2015 at 16:15, Denis Excoffier <iana@denis-excoffier.org<mailto:iana@denis-excoffier.org>> wrote: On 2015-01-06 21:22, Tim Parenti wrote:
+# Some systems implement leap seconds by amortizing the leap second +# over the last few minutes of the day. The frequency of the local +# clock is decreased (or increased) to realize the positive (or +# negative) leap second. This method removes the time step described +# above. Although the long-term behavior of the time scale is correct +# in this case, this method introduces an error during the adjustment +# period both in time and in frequency with respect to the official +# defintion of UTC.
s/defintion/definition/ Regards, Denis Excoffier. -- Tim Parenti
Levine, Judah Dr. wrote:
It is a significant job to make and document the change and to push it out to all of our servers, so I probably won't correct the error for now.
When you fix those trivial typos, could you please also remove trailing spaces from the following three lines in leap-seconds.list? I found them with the shell command "grep -n '[[:space:]]$' leap-seconds.list | sed 's/$/$/'". 134:# above. Although the long-term behavior of the time scale is correct $ 135:# in this case, this method introduces an error during the adjustment $ 136:# period both in time and in frequency with respect to the official $ It's a small thing, but the trailing white space does complicate tz maintenance slightly, particularly now that the popular Git version control system flags them. E.g., please see: https://github.com/eggert/tz/commit/525886015de772fa5a9861ac33b170c3bcadd411 http://mm.icann.org/pipermail/tz/2015-January/021977.html http://mm.icann.org/pipermail/tz/2015-January/021988.html Thanks.
Hello, Sure, I can do that. However, I would have expected that you would not parse a comment line and would skip to the newline character when you read one. Judah Levine Sent from my iPad
On Jan 30, 2015, at 7:50 PM, "Paul Eggert" <eggert@cs.ucla.edu> wrote:
Levine, Judah Dr. wrote:
It is a significant job to make and document the change and to push it out to all of our servers, so I probably won't correct the error for now.
When you fix those trivial typos, could you please also remove trailing spaces from the following three lines in leap-seconds.list? I found them with the shell command "grep -n '[[:space:]]$' leap-seconds.list | sed 's/$/$/'".
134:# above. Although the long-term behavior of the time scale is correct $ 135:# in this case, this method introduces an error during the adjustment $ 136:# period both in time and in frequency with respect to the official $
It's a small thing, but the trailing white space does complicate tz maintenance slightly, particularly now that the popular Git version control system flags them. E.g., please see:
https://github.com/eggert/tz/commit/525886015de772fa5a9861ac33b170c3bcadd411 http://mm.icann.org/pipermail/tz/2015-January/021977.html http://mm.icann.org/pipermail/tz/2015-January/021988.html
Thanks.
On 02/05/2015 06:51 AM, Levine, Judah Dr. wrote:
I would have expected that you would not parse a comment line and would skip to the newline character when you read one.
Yes, we do that. This is not a question of how the tz code operates; it works fine. It's merely a question of the Git version-control system, which complains about trailing white space, because changes to trailing white space cause trivial but annoying differences. Again, it's just a small thing.
On Feb 5, 2015, at 10:38 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 02/05/2015 06:51 AM, Levine, Judah Dr. wrote:
I would have expected that you would not parse a comment line and would skip to the newline character when you read one.
Yes, we do that. This is not a question of how the tz code operates; it works fine. It's merely a question of the Git version-control system, which complains about trailing white space, because changes to trailing white space cause trivial but annoying differences. Again, it's just a small thing.
I assume that this complaining is configurable, so it should be a straightforward matter to disable it selectively for this file, or if that doesn’t work, to disable it entirely. paul
On 05/02/15 16:20, Paul_Koning@dell.com wrote:
On Feb 5, 2015, at 10:38 AM, Paul Eggert <eggert@cs.ucla.edu> wrote: On 02/05/2015 06:51 AM, Levine, Judah Dr. wrote:
I would have expected that you would not parse a comment line and would skip to the newline character when you read one.
Yes, we do that. This is not a question of how the tz code operates; it works fine. It's merely a question of the Git version-control system, which complains about trailing white space, because changes to trailing white space cause trivial but annoying differences. Again, it's just a small thing.
I assume that this complaining is configurable, so it should be a straightforward matter to disable it selectively for this file, or if that doesn’t work, to disable it entirely.
A .gitattributes file containing the following line would selectively ignore whitespace problems when applying patches to the leap-seconds.list file: leap-seconds.list -whitespace See the gitattributes(5) man page for details. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-
Hello, The changes have been applied to the leap second file on the two primary control servers: utcnist (128.138.140.44) utcnist2 (128.138.141.172) The updated files will be pushed out to the other NIST servers in the next few weeks. Best wishes, Judah Levine Time and Frequency Division NIST Boulder On 1/30/2015 7:50 PM, Paul Eggert wrote:
Levine, Judah Dr. wrote:
It is a significant job to make and document the change and to push it out to all of our servers, so I probably won't correct the error for now.
When you fix those trivial typos, could you please also remove trailing spaces from the following three lines in leap-seconds.list? I found them with the shell command "grep -n '[[:space:]]$' leap-seconds.list | sed 's/$/$/'".
134:# above. Although the long-term behavior of the time scale is correct $ 135:# in this case, this method introduces an error during the adjustment $ 136:# period both in time and in frequency with respect to the official $
It's a small thing, but the trailing white space does complicate tz maintenance slightly, particularly now that the popular Git version control system flags them. E.g., please see:
https://github.com/eggert/tz/commit/525886015de772fa5a9861ac33b170c3bcadd411
http://mm.icann.org/pipermail/tz/2015-January/021977.html http://mm.icann.org/pipermail/tz/2015-January/021988.html
Thanks.
-- Judah Levine Time and Frequency Division NIST Boulder
Thanks, I installed the attached patch to the experimental version of the tz database on github, and it should appear in the next release.
Judah Levine <Judah.Levine@nist.gov> wrote on Fri, 6 Feb 2015 at 09:12:41 -0700 in <54D4E7F9.509@nist.gov>:
The updated files will be pushed out to the other NIST servers in the next few weeks.
Am I the only one who is a little concerned that a two-week update time might prove to be a problem in the future? I am not sure that this is an issue worth raising. --jhawk@mit.edu John Hawkinson
participants (9)
-
Arthur David Olson -
Denis Excoffier -
Ian Abbott -
John Hawkinson -
Judah Levine -
Levine, Judah Dr.
-
Paul Eggert -
Paul_Koning＠dell.com -
Tim Parenti