Martin Burnicki wrote:
> 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.
PTP never does that. IEEE-1588 has a different epoch but is based on
TAI, which
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
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
On Wed, Jan 16, 2019 at 2:00 PM Jim Palfreyman 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
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 wrote:
> Yes correct. NTP behaves as intended. I called NTP issue as that's
> what commonly called in
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
On Wed, Jan 16, 2019 at 7:00 AM Fiorenzo Cattaneo 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
Hi
Welcome to yet another chapter in the very long book “why leap seconds are
bad”.
There are a lot of posts going into may of the ways they messes up code and
updates.
Keeping a library up to date with a leap second that might be a few months out
…. yikes …..
Recompiling all your code (if
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
f...@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
There are few libraries which offer time unadjusted for leap seconds,
like TAI time:
https://en.cppreference.com/w/cpp/chrono/tai_clock
Some other libraries (typically in written in languages which very few
people use like haskell ) offer leapsecond support, but the
fundamental problem (as
AFIK no programming systems professing POSIX compliance implements Leap
Seconds. There is however a timezone UTCLeapSeconds will allow this apparently.
>> t1.TimeZone = ‘UTCLeapSeconds'
Obviously youR TZ data base needs to have it and your Python needs to be at the
required level;
My test
I double check the Python code, and I can confirm it does not take
LEAP seconds into account. I highly doubt you will find standard time
libraries for the most common languages which will deal with LEAP
seconds. They would rather just ignore it and have one less of a
headache to worry about
I'm working with a variety of things which work in UTC or GPS
week/millisecond, so we're doing a lot of conversion back and forth.
(the spacecraft puts out time in week:millisecond, all the ground
systems processing is in UTC)
The question comes up when converting back and forth, and whether
14 matches
Mail list logo
