[time-nuts] leapseconds, converting between GPS time (week, second) and UTC

[Fiorenzo Cattaneo]

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 at 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 at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.