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

[Warner Losh]

On Tue, Jan 15, 2019 at 12:41 PM Rob Seaman <seaman at lpl.arizona.edu> wrote:

> Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of
> IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The
> various libraries and operating systems listed deal with none of the
> reference time scales (GPS, UTC, or TAI, for that matter) completely and
> correctly.
>
> This suggests strongly that those models of time are fatally flawed and
should be revisited.

> There's no obvious connection here with astronomical use cases. We rely on
> our reference clocks' vendor to have implemented IS-GPS-200J and relevant
> standards correctly. These devices operate off single board linux cards,
> but I presume they wrote the critical code themselves to handle leap
> seconds, but also other precision timekeeping issues not entertained by
> POSIX and other mass market software. Our clocks handle time scales other
> than UTC, but since our customer (NASA PDCO) specifies UTC, that's what we
> deliver.
>
Spinning rocks are hard, eh? the non-uniform nature of UTC is a big reason
it's hard to implement correctly in software (especially when there's code
size or speed constraints). It's impossible to implement without tables
that must constantly be updated. While this is natural and acceptable in
many environments, it presents operational difficulties for others. The ITU
standard that tries to keep the spinning rock and atomic time in sync is
flawed in that it doesn't adequately accommodate all situations. POSIX has
similar sorts of flaws, but the details differ.

> The bread-and-butter leap second discussions on this list seem irrelevant
> to simply meeting an engineering requirement to adhere to whatever
> standard. If POSIX, python, excel, whatever don't provide canned tools to
> convert seamlessly between GPS and UTC, or to handle format conversions
> from week:ms to sexagesimal, such tools must be implemented outside those
> languages/libraries. There are a vast number of other science-related data
> engineering details that POSIX (for example) also does not implement.
>
Yes. Despite the efforts of the POSIX committee to make it easy to
implement time, those efforts have resulted in a fatally flawed standard
that leads to the "1 second errors are fine, don't bother me" attitude that
pervades many adjacent APIs to the POSIX APIs. It was the number one
frustration that I had when I had to deal with vendors that didn't get the
leap seconds pedantically correct and didn't give a @!##@ that they didn't
because there was no financial penalty for not doing so. It was maddening.

Warner


> Rob Seaman, Lunar and Planetary Laboratory
>
> --
> On 1/15/19 11:50 AM, Tom Van Baak wrote:
>
> Jim -- I'm replying via the LEAPSECS list because we love leap second questions here.
>
> List -- Jim is a long-time member of time-nuts, works at JPL, and does wonderful stuff.
>
> From Jim Lux:
>
> 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
> various libraries handle leap seconds correctly.
> For now, I can use a hack of not computing back to 6 Jan 1980, but use
> an epoch like 15 Dec 2018 (week 2031: 518,400.000 seconds) and hope
> there's no leap second in the offing.
>
> Yes, that's one way. But that doesn't sound safe or correct to me.
>
>
> For instance, in Python, if I do a datetime(2016,12,31,0,0,0) +
> timedelta(hours=30) does it come out as 1/1/2017 6:00:00 or 5:59:59  (it
> comes out 0600)
>
> Similarly, does Excel's time formatting allow for some minutes having an
> extra second, or does it just assume all minutes are 60 seconds.
>
> Nope. All minutes have 60 seconds in Excel. And in Windows. And in Unix/POSIX. Really any computer system that uses a fixed "epoch" and a ticking "counter" is ruined by leap seconds. The systems differ in their epoch's, they all differ in their counters, they can all be set to UTC, except they all fail when there's a positive or negative leap second.
>
>
> I'll probably test it for the cases I'm interested in (Ruby, Python,
> Excel, Matlab, Octave), but if someone else has already done it, then
> I've got something to cross check against.
>
> This is a good question for LEAPSECS. I suspect those packages are well-known here.
>
>
> (python does NOT know about leap seconds)
>
> import datetime
>
> d = datetime.datetime(2016,12,31)
>
> dt = datetime.timedelta(hours=30)
>
> d
> Out[4]: datetime.datetime(2016, 12, 31, 0, 0)
>
> dt
> Out[5]: datetime.timedelta(1, 21600)
>
> d+dt
> Out[6]: datetime.datetime(2017, 1, 1, 6, 0)
>
> Right, this is typical for almost any software developed anywhere. Leap seconds are such a weird exception, almost no commercial software, web frontend or backend, or mobile phones, or mobile apps deal with them correctly.
>
> I'm hoping a number of LEAPSECS members can chime in. There are astronomers here who must be used to solving issues like this, in python or other tools, so their input would be valuable.
>
> /tvb
>
> _______________________________________________
> LEAPSECS mailing listLEAPSECS at leapsecond.comhttps://pairlist6.pair.net/mailman/listinfo/leapsecs
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190115/c87d458a/attachment-0001.html>