Re: [time-nuts] leapseconds, converting between GPS time (week, second) and UTC
fio@cattaneo.us said:
we switch in and out of DST, like applications crashing because NTP applies
the 1 hour change in a discontinous manner, as well as iphone alarms not
working when the DST date is modified?).
For the record, NTP works in UTC. It doesn't know anything about time zones
or DST.
--
These are my opinions. I hate spam.
Yes of course you are right. NTP timebase (based on UTC with an epoch
of 1900-01-01 00:00:00, or its representation in Unix time - seconds
since 1970-01-01 00:00:00) is timezone independent.
I just wanted to make the point that in the IT world (I've worked for
Amazon, Microsoft, Twitter and now I work for another major IT
supplier) we keep spending billions of dollars to maintain really
crappy and cruddy libraries which deal with timezones, and still get
plenty of bugs every time.
Not to mention NTP issues when leapseconds are addded (the only
company which handled the last leap second correctly was google, as
they slowly slewed at the rate of 1s/hour).
So in such an abysmal situation, I would be hugely surprised to find
commercial libraries that handle UTC, UT, TAI and GPS time correctly.
It's simply not a priority.
There are a few libraries here and there that supposedly handle it
correctly, but I wouldn't count on them unless they get heavily
tested.
That was my point, sorry if I was confusing.
-- Fio Cattaneo
Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."
On Wed, Jan 16, 2019 at 3:40 AM Hal Murray hmurray@megapathdsl.net wrote:
fio@cattaneo.us said:
we switch in and out of DST, like applications crashing because NTP applies
the 1 hour change in a discontinous manner, as well as iphone alarms not
working when the DST date is modified?).
For the record, NTP works in UTC. It doesn't know anything about time zones
or DST.
--
These are my opinions. I hate spam.
Fiorenzo Cattaneo wrote:
Yes of course you are right. NTP timebase (based on UTC with an epoch
of 1900-01-01 00:00:00, or its representation in Unix time - seconds
since 1970-01-01 00:00:00) is timezone independent.
I just wanted to make the point that in the IT world (I've worked for
Amazon, Microsoft, Twitter and now I work for another major IT
supplier) we keep spending billions of dollars to maintain really
crappy and cruddy libraries which deal with timezones, and still get
plenty of bugs every time.
Not to mention NTP issues when leapseconds are addded
It's not an NTP issue. NTP only forwards the leap second announcement to
the kernel, if the kernel supports this. It's up to the kernel how a
leap second is handled. Most *ix kernels just step the time back by
default, which is confusing for applications that haven't been designed
to cope with such steps.
Except for latest Windows server versions, Windows doesn't care about
leap seconds at all, and the system time simply off by 1 second after a
leap second event. This offset persists until some time synchronization
software corrects it.
(the only
company which handled the last leap second correctly was google, as
they slowly slewed at the rate of 1s/hour).
This is just a hack. During the slewing the time is off by up to +/- 0.5
s, or even up to 1 s depending on the kind of slewing. This can mess up
applications that require a very accurate absolute time.
Martin
Yes correct. NTP behaves as intended. I called NTP issue as that's
what commonly called in the industry, but in reality it's applications
which are unable to deal with time steppings.
The LEAP second smearing that Google (and others too, now AWS as well)
is as you say, just a hack to avoid application problems.
I am starting to realize I need to very precise (no pun intended) when
writing on this mailing list. Please accept my apologies, this is my
first thread I contribute to.
-- Fio Cattaneo
Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."
On Wed, Jan 16, 2019 at 9:01 AM Martin Burnicki
martin.burnicki@burnicki.net wrote:
Fiorenzo Cattaneo wrote:
Yes of course you are right. NTP timebase (based on UTC with an epoch
of 1900-01-01 00:00:00, or its representation in Unix time - seconds
since 1970-01-01 00:00:00) is timezone independent.
I just wanted to make the point that in the IT world (I've worked for
Amazon, Microsoft, Twitter and now I work for another major IT
supplier) we keep spending billions of dollars to maintain really
crappy and cruddy libraries which deal with timezones, and still get
plenty of bugs every time.
Not to mention NTP issues when leapseconds are addded
It's not an NTP issue. NTP only forwards the leap second announcement to
the kernel, if the kernel supports this. It's up to the kernel how a
leap second is handled. Most *ix kernels just step the time back by
default, which is confusing for applications that haven't been designed
to cope with such steps.
Except for latest Windows server versions, Windows doesn't care about
leap seconds at all, and the system time simply off by 1 second after a
leap second event. This offset persists until some time synchronization
software corrects it.
(the only
company which handled the last leap second correctly was google, as
they slowly slewed at the rate of 1s/hour).
This is just a hack. During the slewing the time is off by up to +/- 0.5
s, or even up to 1 s depending on the kind of slewing. This can mess up
applications that require a very accurate absolute time.
Martin
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On Wed, Jan 16, 2019 at 7:00 AM Fiorenzo Cattaneo fio@cattaneo.us wrote:
Not to mention NTP issues when leapseconds are addded (the only
company which handled the last leap second correctly was google, as
they slowly slewed at the rate of 1s/hour).
Note that the smear rate is not 1 s/hour, but 1 s over 24 hours
(41.667 ms/hour). There is no slop; smeared time is now a precisely
defined and invertible function of UTC with leap seconds.
For the record, when using R, the package "lubridate" (which is part of the
brilliant "tidyverse") does handle leap seconds.
Dr Jim Palfreyman
On Thu, 17 Jan 2019 at 07:08, Fiorenzo Cattaneo fio@cattaneo.us wrote:
Yes correct. NTP behaves as intended. I called NTP issue as that's
what commonly called in the industry, but in reality it's applications
which are unable to deal with time steppings.
The LEAP second smearing that Google (and others too, now AWS as well)
is as you say, just a hack to avoid application problems.
I am starting to realize I need to very precise (no pun intended) when
writing on this mailing list. Please accept my apologies, this is my
first thread I contribute to.
-- Fio Cattaneo
Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."
On Wed, Jan 16, 2019 at 9:01 AM Martin Burnicki
martin.burnicki@burnicki.net wrote:
Fiorenzo Cattaneo wrote:
Yes of course you are right. NTP timebase (based on UTC with an epoch
of 1900-01-01 00:00:00, or its representation in Unix time - seconds
since 1970-01-01 00:00:00) is timezone independent.
I just wanted to make the point that in the IT world (I've worked for
Amazon, Microsoft, Twitter and now I work for another major IT
supplier) we keep spending billions of dollars to maintain really
crappy and cruddy libraries which deal with timezones, and still get
plenty of bugs every time.
Not to mention NTP issues when leapseconds are addded
It's not an NTP issue. NTP only forwards the leap second announcement to
the kernel, if the kernel supports this. It's up to the kernel how a
leap second is handled. Most *ix kernels just step the time back by
default, which is confusing for applications that haven't been designed
to cope with such steps.
Except for latest Windows server versions, Windows doesn't care about
leap seconds at all, and the system time simply off by 1 second after a
leap second event. This offset persists until some time synchronization
software corrects it.
(the only
company which handled the last leap second correctly was google, as
they slowly slewed at the rate of 1s/hour).
This is just a hack. During the slewing the time is off by up to +/- 0.5
s, or even up to 1 s depending on the kind of slewing. This can mess up
applications that require a very accurate absolute time.
Martin
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On Wed, Jan 16, 2019 at 2:00 PM Jim Palfreyman jim77742@gmail.com wrote:
For the record, when using R, the package "lubridate" (which is part of the
brilliant "tidyverse") does handle leap seconds.
astropy's time object in Python
(http://docs.astropy.org/en/stable/time/index.html) can also handle
leap seconds:
t1=Time('2016-12-31 23:00:00', scale='utc')
t2=Time('2017-01-01 1:00:00', scale='utc')
td = t2-t1
print(td.sec)
7201.0
It supports UTC, UT1, TAI, TCB, TCG, TDB, TT and local
Cheers,
Tim
Fiorenzo Cattaneo wrote:
Yes correct. NTP behaves as intended. I called NTP issue as that's
what commonly called in the industry, ...
Agreed, but that's simply wrong. If you ran a PTP daemon instead of an
NTP daemon you had exactly the same problems when the PTP daemon passes
a leap second announcement to the kernel.
... but in reality it's applications
which are unable to deal with time steppings.
The LEAP second smearing that Google (and others too, now AWS as well)
is as you say, just a hack to avoid application problems.
I am starting to realize I need to very precise (no pun intended) when
writing on this mailing list.
;-)
Please accept my apologies, this is my first thread I contribute to.
No need to apologize, IMO. I also post only rarely on this list because
most other folks here are much more familiar with the kind of stuff
discussed here. Anyway, very interesting reading. ;-)
Martin
Jim Palfreyman wrote:
For the record, when using R, the package "lubridate" (which is part of the
brilliant "tidyverse") does handle leap seconds.
Basically it's good that there a particular programming environments
that handle leap seconds internally.
As far as I know there's also Java which does some kind of intermnal
smearing (UTC-SLS), and also Python can do this.
The problem I see is if such an application has to exchange date which
has been written using a different programming environment.
Martin