Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
Le 16 janv. 2015 à 08:42, Harlan Stenn st...@ntp.org a écrit :
Terje Mathisen writes:
cmad...@cmadams.net (Chris Adams) wrote:
strange response!
Le 11 janv. 2015 à 21:18, Paul tik-...@bodosom.net a écrit :
Why do folks mention leap seconds on this list?
part of the NTP protocol deals with the scheduling insertion/deletion of leap
seconds.
Why do people point to leap-seconds.NTPtimestamp instead of just
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote:
Miroslav Lichvar wrote:
Here is a test showing error between two clients of a server
smearing.a large offset. With the cosine function you can see a large
spike when smearing started.
On 01/27/2015 10:16 AM, Terje Mathisen wrote:
Jochen Bern wrote:
Because they chose the long window (about one day) and made it exceed
the time an NTP peering needs to *act* on the perceived offset, yes. If
That's a a key feature of the long adjustment period: The smearing takes
so long
Jochen Bern wrote:
On 01/26/2015 01:03 PM, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number
Miroslav Lichvar wrote:
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote:
Miroslav Lichvar wrote:
Here is a test showing error between two clients of a server
smearing.a large offset. With the cosine function you can see a large
spike when smearing started.
Terje Mathisen terje.mathi...@tmsw.no writes:
The derivatives of sine/cosine are of course +/- cosine/sine, so they
stay smooth at all levels.
The point is that it is not smooth where it joins on to the regular
passage of time... It is possible to do this in an infinitely smooth
way, but using
David Malone wrote:
Terje Mathisen terje.mathi...@tmsw.no writes:
The derivatives of sine/cosine are of course +/- cosine/sine, so they
stay smooth at all levels.
The point is that it is not smooth where it joins on to the regular
passage of time... It is possible to do this in an infinitely
Jochen Bern wrote:
On 01/27/2015 10:16 AM, Terje Mathisen wrote:
Jochen Bern wrote:
Because they chose the long window (about one day) and made it exceed
the time an NTP peering needs to *act* on the perceived offset, yes. If
That's a a key feature of the long adjustment period: The smearing
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via NTP
Does that read there's *several* teams working on NTPv5 and not
communicating with each other right now ... ?
The ITU has just met in Geneva and discussed the
On 01/22/2015 07:04 PM, William Unruh wrote:
General relativity assures us that time exists and is measured by a
metric. Take that metric and define a proper time say at the center of
the earth.
(Bad choice because relativity says that clocks down the gravity well
run faster, but we've been
Terje Mathisen terje.mathi...@tmsw.no writes:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number of defined
Jochen Bern wrote:
Sorry for the delay, I'm *still* not back to my usual workplace ...
On 01/21/2015 11:39 AM, Mike Cook wrote:
I couldn’t find a definition of a monotonous function. Does it exist?
As David already suggested, I learnt my math in Germany - and switched
to CS before taking a
On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a half
cosine to distribute the offset, which means that they have a time function
which is both continuous and monotonic, as well as having an infinite number
On 01/26/2015 01:03 PM, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number of defined
On 2015-01-26, Terje Mathisen terje.mathi...@tmsw.no wrote:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number
On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote:
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via NTP
Does that read there's *several* teams working on NTPv5 and not
communicating with each other right now
On 2015-01-26, William Unruh un...@invalid.ca wrote:
On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote:
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via NTP
Does that read there's *several* teams working on
On 26/01/15 17:11, William Unruh wrote:
physical principle ( the frequency of oscillation of a cesium atom in a
XX
certain transition) and the rotation of the earth. It used to be defined
^not
It's a quantum
David Malone wrote:
Terje Mathisen terje.mathi...@tmsw.no writes:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite
Miroslav Lichvar wrote:
On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a half
cosine to distribute the offset, which means that they have a time function
which is both continuous and monotonic, as well as
On 2015-01-26, David Woolley david@ex.djwhome.demon.invalid wrote:
On 26/01/15 17:11, William Unruh wrote:
physical principle ( the frequency of oscillation of a cesium atom in a
XX
certain transition) and the rotation of the earth. It used
I'm expecting that NTPv5 will include things like the timescale used by
the timestamp, so as long as the systems agree on how to convert
timescales if they are not the same between the client and server
(hello, General Timestamp API) it will be OK if an NTPv4 or NTPv5 box
talks to an NTPv5 box, as
Jochen Bern writes:
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via =
NTP
Does that read there's *several* teams working on NTPv5 and not
communicating with each other right now ... ?
Nobody has talked to me,
Sorry for the delay, I'm *still* not back to my usual workplace ...
On 01/21/2015 11:39 AM, Mike Cook wrote:
I couldn’t find a definition of a monotonous function. Does it exist?
As David already suggested, I learnt my math in Germany - and switched
to CS before taking a shot at a PhD, which
Anyone wanting to check whether they are being fed spurious leap-second
information may like to try my Leap Trace program, available as a
Windows GUI and command-line program, and as a Perl script for other OS.
http://www.satsignal.eu/software/net.htm#NTPLeapTrace
--
Cheers,
David
Web:
On Friday, January 23, 2015 at 3:55:02 AM UTC-5, Marco Marongiu wrote:
On 21/01/15 15:31, Mike S wrote:
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering
On 1/23/2015 2:03 PM, schmidt.r...@gmail.com wrote:
What shall you program
about the end of June, 2016, or December, 2020? What will be the
interval of time between now and then?
Depends. What are you doing which requires 1 second accuracy a year or 5
from now? Does it need to happen at a
William Unruh un...@invalid.ca writes:
General relativity assures us that time exists and is measured by a
metric. Take that metric and define a proper time say at the center of
the earth. Now one can ask whether TAI or UTC is a function of that
time.
As Mike points out, you've subtracted
On 21/01/15 15:31, Mike S wrote:
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering practices.
That's right. Instead of recognizing that the world rotates on it's
On 21/01/15 10:39, Mike Cook wrote:
I couldn’t find a definition of a monotonous function.
It's an obvious mis-choice of words by someone whose name suggests they
aren't native English speaker. It clearly is intended to mean
monotonic. See
William Unruh un...@invalid.ca writes:
Note UTC differs from TAI by an interger number of seconds, AND that
integer changes with the leap second. Ie, it cannot be continuous if TAI
is continuous.
That assumes that UTC can be represented as a real number with the
standard topology, which doesn't
Mike S schrieb:
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering practices.
That's right. Instead of recognizing that the world rotates on it's own,
they want to
On 1/22/2015 1:04 PM, William Unruh wrote:
General relativity assures us that time exists and is measured by a
metric...
still 1 second different in the two scales. And for Jun 30
23:59:59.9 and Jul 1 00:00:00.1
while TAI says that difference is .2 sec, UTC says it is
Mike S writes:
Both TAI and UTC are continuous, and could in a non-standard way, be
represented by real numbers (Time, below), where they wouldn't differ.
TAI and UTC only differ in how they're labelled, as you say. It's
POSIX which isn't monotonic or continuous, it repeats leap seconds.
On 2015-01-22 11:04, William Unruh wrote:
On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote:
William Unruh un...@invalid.ca writes:
Note UTC differs from TAI by an interger number of seconds, AND that
integer changes with the leap second. Ie, it cannot be continuous if TAI
is
On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote:
William Unruh un...@invalid.ca writes:
Note UTC differs from TAI by an interger number of seconds, AND that
integer changes with the leap second. Ie, it cannot be continuous if TAI
is continuous.
That assumes that UTC can be
On 1/22/2015 5:45 AM, David Malone wrote:
That assumes that UTC can be represented as a real number with the
standard topology, which doesn't seem to be what TF.460 says. It
describes each second as labelled, which means that you have to
stitch together all possible unit intervals for each
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering practices.
That's right. Instead of recognizing that the world rotates on it's own,
they want to change reality so
Jochen Bern wrote:
On 01/19/2015 08:42 AM, William Unruh wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
[...]
You two *both* need to get your terminology (and its definitions) right.
[...]
Wow, IMO this is *very* good summary of the problem, and explanation of
the reasons for
Programmers universally compute the number of days between two dates by
determining the seconds of the two dates (by using a function such as
getTimeInMillis() for each date), computing the difference in seconds
between the two dates, and dividing the difference by 86,400.
I proved this to myself
On 01/20/2015 10:58 AM, Martin Burnicki wrote:
Wow, IMO this is *very* good summary of the problem, and explanation of
the reasons for it.
Thanks, but after pondering the topic another night, I found my treatise
to still be faulty. :-} Let me try to amend:
---
The smaller point
On 1/20/2015 6:14 PM, Jochen Bern wrote:
So, what*function* might people be thinking of when they assert those
properties to apply (or not) to timescales?
TAI = UTC(x) and UTC = TAI(x). And that's part of the problem.
There seems to be the thought that if you do that across a leap second,
Le 21 janv. 2015 à 07:18, Terje Mathisen terje.mathi...@tmsw.no a écrit :
Mike S wrote:
The real problem is systems (POSIX, particularly), which incorrectly
handle time, despite having over 40 years to get it right. They try to
please everyone, while pleasing no one. POSIX tracks and does
Mike S wrote:
The real problem is systems (POSIX, particularly), which incorrectly
handle time, despite having over 40 years to get it right. They try to
please everyone, while pleasing no one. POSIX tracks and does
calculations on determinate intervals (seconds since 1/1/1970, and every
minute
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap second, there are 86401 SI seconds in
I AM clearly
William Unruh un...@invalid.ca wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap second, there
On 19/01/15 12:15, Mike S wrote:
You clearly misunderstood TF.460, because you still have it wrong. There
is no discontinuity, the two scales merely count time differently. This
is how the time of the next leap second will be enumerated in each:
You are relying on an appendix that deals with
[And this is why I wonder why leap seconds are discussed here.]
On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote:
You clearly misunderstood TF.460
You're using the wrong reference. Try this one from 2007:
On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote:
You're citing a internal letter, from one BIPM group to another, asking
them to bring something before the ITU. It's not normative, it's not
informational, it's just correspondence.
That doesn't make any sense. When the
On 1/19/2015 8:05 AM, David Woolley wrote:
You are relying on an appendix that deals with representation of dates.
The main part of the standard is worded in terms of their being missing
seconds.
How proving that you're unable to provide a quote to back up what is,
quite simply, a blatant
On 1/19/2015 10:22 AM, Paul wrote:
On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote:
You're citing a internal letter, from one BIPM group to another, asking
them to bring something before the ITU. It's not normative, it's not
informational, it's just correspondence.
That
On 1/19/2015 9:04 AM, Paul wrote:
[And this is why I wonder why leap seconds are discussed here.]
On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote:
You clearly misunderstood TF.460
You're using the wrong reference.
Huh? You plainly don't understand the relationships or
On 1/19/2015 2:42 AM, William Unruh wrote:
I quoted from the document you yourself pointed me at. TAI is
continuous. UTC differes from TAI by and interger number of seconds, and
that integer changes when a leap second occurs. If x is continous x-n
where n changes at some time, is NOT
William Unruh un...@invalid.ca wrote:
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote:
William Unruh un...@invalid.ca wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand
On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com wrote:
Again, you need to up your understanding of standards terminology.
No, if you're going to use jargon you should provide the meanings you're
using. Since you clearly have your own version of reality it will help the
rest of
On 1/19/2015 11:58 AM, Paul wrote:
On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com
mailto:mi...@flatsurface.com wrote:
Again, you need to up your understanding of standards terminology.
No, if you're going to use jargon you should provide the meanings you're
using. Since
On 1/19/2015 11:56 AM, William Unruh wrote:
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote:
I am not sure what you mean by sees, but I cant figure a meaning
that would be compatible with the fact that UTC clearly identifies
86401 seconds on the day the leap second occurs.
If you ask utc how
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote:
William Unruh un...@invalid.ca wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand how leap seconds work. You're
On 01/19/2015 08:42 AM, William Unruh wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 31536000 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap
On 2015-01-18 16:04, William Unruh wrote:
UTC always has 86400 seconds per year.
ITYM POSIX time always has 86.4ks/day - by that definition POSIX keeps
legal civil time using mean solar seconds, not SI seconds or leap seconds.
Any correspondence between POSIX time, SI seconds, UTC, or TAI, is
On 2015-01-18, Mike S mi...@flatsurface.com wrote:
On 1/14/2015 3:50 AM, Rob wrote:
No, it is the inadvertent decision to use UTC as a monotonic clock that
causes the trouble.
UTC is monotonic. It is POSIX time which has discontinuities when it
tries to represent UTC.
TAI is monotonic and
On 2015-01-18, Mike S mi...@flatsurface.com wrote:
On 1/13/2015 11:46 PM, William Unruh wrote:
That is a translation from seconds to ymdhms. The problem is not there.
it is in the UTC seconds.
In UTC one second disappears after the leap second, but not before or
during. Thus UTC seconds
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap second, there are 86401 SI seconds in
that year, that's the whole point. You may also be interested to
On 1/18/2015 7:15 PM, Mike S wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap second, there are 86401 SI seconds in
that year
That clearly
On 1/14/2015 3:50 AM, Rob wrote:
No, it is the inadvertent decision to use UTC as a monotonic clock that
causes the trouble.
UTC is monotonic. It is POSIX time which has discontinuities when it
tries to represent UTC.
___
questions mailing list
Terje Mathisen wrote:
OK, so exactly as encoded in the right zone info, there is no leap
second until the table is updated/patched.
And yet there is no expiration date in the TZDB's leap second file
(which is also used for the right time zones), so you don't know if
there is no upcoming leap
On 2015-01-16, Chris Adams cmad...@cmadams.net wrote:
Once upon a time, Phil W Lee p...@lee-family.me.uk said:
For the tiny number of programs which really need UTC (not TAI), it
would just be a different number, but the only thing I know of which
really needs UTC rather than TAI would be
On 01/16/2015 05:41 AM, Chris Adams wrote:
I think one problem with OS clocks in TAI is that counting it correctly
requires active/on-going maintenance at unknownable intervals for all
systems that use any form of timestamps (including for example anything
that uses network file systems).
Jochen Bern writes:
...
We all know that the current NTP protocol leans toward UTC, and
doesn't address any leap seconds except the one that might be at hand
right now. In recent posts to this list, I've read about plans for an
NTPng that allows for different timescales, but still suggests
On 15/01/15 07:56, Terje Mathisen wrote:
Did we have a leap second last June? Or did you intend to check for 2015?
Oops. I did get it right in the dry run, but not in the run I actually
used:
david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015
86400 seconds'
Wed Jul
Once upon a time, Phil W Lee p...@lee-family.me.uk said:
For the tiny number of programs which really need UTC (not TAI), it
would just be a different number, but the only thing I know of which
really needs UTC rather than TAI would be programs to assist with
astronomy or astral navigation.
I
David Woolley wrote:
On 15/01/15 07:56, Terje Mathisen wrote:
Did we have a leap second last June? Or did you intend to check for 2015?
Oops. I did get it right in the dry run, but not in the run I actually
used:
david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015
cmad...@cmadams.net (Chris Adams) wrote:
Once upon a time, Phil W Lee p...@lee-family.me.uk said:
For the tiny number of programs which really need UTC (not TAI), it
would just be a different number, but the only thing I know of which
really needs UTC rather than TAI would be programs to
Terje Mathisen writes:
cmad...@cmadams.net (Chris Adams) wrote:
Also, you can't properly represent future timestamps (necessary for some
things) as seconds since an epoch, and that's pretty widely used. By
that I mean that the number of seconds between 2015-06-30 23:59:00 and
2015-07-01
David Woolley wrote:
On 14/01/15 16:37, Terje Mathisen wrote:
The calls I'm thinking of are those you make to convert an OS-supplied
time_t (file) system timestamp to YMDHMS etc.
Those calls have no need to be in the kernel, and they are not in
Unix/Linux systems.
The standard
On 14/01/15 16:37, Terje Mathisen wrote:
The calls I'm thinking of are those you make to convert an OS-supplied
time_t (file) system timestamp to YMDHMS etc.
Those calls have no need to be in the kernel, and they are not in
Unix/Linux systems.
I.e. even Windows (which uses a seconds-based
On 01/13/2015 09:33 AM, Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach, where
they smear the leap second over something like a day, [...]
For distributed logging you have to use the same method for every single
node, but that is the case today as
On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen terje.mathi...@tmsw.no
wrote:
By _far_ the largest majority of all system time calls are asking for the
_current_ time, right?
Are there (common) systems that have kernel calls for other than the
current time?
Jochen Bern wrote:
On 01/13/2015 09:33 AM, Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach, where
they smear the leap second over something like a day, [...]
For distributed logging you have to use the same method for every single
node, but that is the
Jochen Bern wrote:
On 01/13/2015 09:33 AM, Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach, where
they smear the leap second over something like a day, [...]
For distributed logging you have to use the same method for every single
node, but that is the
Paul wrote:
On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen terje.mathi...@tmsw.no
wrote:
By _far_ the largest majority of all system time calls are asking for the
_current_ time, right?
Are there (common) systems that have kernel calls for other than the
current time?
The calls I'm
On 2015-01-14, Erwan David er...@rail.eu.org wrote:
Harlan Stenn st...@ntp.org disait le 01/13/15 que :
Martin Burnicki writes:
Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach,
where they smear the leap second over something like a day, might be
one
William Unruh un...@invalid.ca wrote:
That is a translation from seconds to ymdhms. The problem is not there.
it is in the UTC seconds.
In UTC one second disappears after the leap second, but not before or
during. Thus UTC seconds numbering is simply disconinuous (jumps back) .
And it is that
William Unruh wrote:
Now you could have the computer run in TAI and then do the translation
in userland software. But of course since most things expect utc
seconds, every call to the clock would require you figuring out what the
offset from utc to tai is, and subtract that number, making time
On 2015-01-14, Phil W Lee p...@lee-family.me.uk wrote:
brian utterback brian.utterb...@oracle.com considered Mon, 12 Jan
2015 04:29:21 GMT the perfect time to write:
On 1/11/2015 4:56 PM, Rob wrote:
Michael Moroney moro...@world.std.spaamtrap.com wrote:
If I have a system synchronized with a
Harlan Stenn st...@ntp.org disait le 01/13/15 que :
Martin Burnicki writes:
Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach,
where they smear the leap second over something like a day, might be
one of the better workarounds.
This won't work for a
Erwan David writes:
Harlan Stenn st...@ntp.org disait le 01/13/15 que :
Martin Burnicki writes:
Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach,
where they smear the leap second over something like a day, might be
one of the better workarounds.
Brian Utterback wrote:
On 1/12/2015 6:29 AM, Mike Cook wrote:
Not true. That would violate POSIX. There is no properly implements,
or right thing.
Perhaps you're unaware that POSIX isn't the One True Operating System
specification.
Properly implements means it follows the well defined, 40
[Context is google-smear.]
For distributed logging you have to use the same method for every single
node, but that is the case today as well. :-(
I.e. with one domain smearing and another stepping, the times between them
will be skewed over the entire smearing period.
How often do people
Hal Murray writes:
[Context is google-smear.]
For distributed logging you have to use the same method for every single
node, but that is the case today as well. :-(
I.e. with one domain smearing and another stepping, the times between them
will be skewed over the entire smearing
Harlan Stenn wrote:
Marco Marongiu writes:
On 12/01/15 06:10, William Unruh wrote:
I also admit I do not know how windows impliments leap
seconds.
I don't have a reference, but I remember that at the time of the latest
leap second I read that Windows will half the clock speed at 23:59:59 so
Terje Mathisen wrote:
Brian Utterback wrote:
On 1/12/2015 6:29 AM, Mike Cook wrote:
Not true. That would violate POSIX. There is no properly implements,
or right thing.
Perhaps you're unaware that POSIX isn't the One True Operating System
specification.
Properly implements means it follows
On 13/01/2015 08:58, Hal Murray wrote:
[]
How often do people working with log files from 2 systems care about
fractions of a second?
I am comparing log files with a user in another country, where we are
looking at errors in satellite data. As there can be many messages per
second, using
Marco Marongiu wrote:
On 12/01/15 11:48, Martin Burnicki wrote:
Fortunately Dave Hart had some time to have a closer look at this, and
fix it for 4.2.6, so unless something has been broken again in the mean
time it should be fixed in 4.2.6 and later, and should work correctly.
Let me
David Taylor writes:
On 13/01/2015 08:58, Hal Murray wrote:
[]
How often do people working with log files from 2 systems care about
fractions of a second?
I have spoken with enterprise users who have to correlate logging
timestamps between 50-200 (or more) systems in cloud deployments and
Martin Burnicki writes:
Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach,
where they smear the leap second over something like a day, might be
one of the better workarounds.
This won't work for a bunch of folks. Other folks *hate* this approach
because
Harlan Stenn writes:
David Taylor writes:
On 13/01/2015 08:58, Hal Murray wrote:
[]
How often do people working with log files from 2 systems care about
fractions of a second?
I have spoken with enterprise users who have to correlate logging
timestamps between 50-200 (or more)
On 12/01/15 06:10, William Unruh wrote:
I also admit I do not know how windows impliments leap
seconds.
I don't have a reference, but I remember that at the time of the latest
leap second I read that Windows will half the clock speed at 23:59:59 so
that it reaches 00:00:00 at the right time.
On 1/11/2015 11:32 PM, brian utterback wrote:
On 1/11/2015 9:44 PM, Mike S wrote:
On 1/11/2015 7:16 PM, William Unruh wrote:
If that public source is responsible it will pass on to your
system the fact that there is a leapsecond, and your system will stop
for a second at the last second of
1 - 100 of 131 matches
Mail list logo
