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

[Fiorenzo Cattaneo]

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 (remember all the bugs that pop up even when
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?).

The C++ boost time library docs seem to imply it's possible to use
them and have them account for LEAP seconds:
https://www.boost.org/doc/libs/1_58_0/doc/html/date_time.html

What is worse is tha the POSIX standard requires a day to be 86400
seconds, and pretty much all the code which relies on POSIX makes such
assumption, in fact in my experience the day length is usually
hardcoded to 86400 seconds:
https://www.ucolick.org/~sla/leapsecs/right+gps.html

=================================


fcattane at linux-mint-64:~$ python
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> import datetime
>>>
>>> # last leap second got added on 1 Jan 2017
... #
...
>>> unix_time_2017_01_01 = 1483228800
>>>
>>>
>>>
>>> unix_time_2017_01_01
1483228800
>>>


>>> time.gmtime(unix_time_2017_01_01 - 2)
time.struct_time(tm_year=2016, tm_mon=12, tm_mday=31, tm_hour=23,
tm_min=59, tm_sec=58, tm_wday=5, tm_yday=366, tm_isdst=0)

>>> time.gmtime(unix_time_2017_01_01 - 1)
time.struct_time(tm_year=2016, tm_mon=12, tm_mday=31, tm_hour=23,
tm_min=59, tm_sec=59, tm_wday=5, tm_yday=366, tm_isdst=0)

>>> time.gmtime(unix_time_2017_01_01)
time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=0,
tm_min=0, tm_sec=0, tm_wday=6, tm_yday=1, tm_isdst=0)

>>> time.gmtime(unix_time_2017_01_01 + 1)
time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=0,
tm_min=0, tm_sec=1, tm_wday=6, tm_yday=1, tm_isdst=0)

>>> time.gmtime(unix_time_2017_01_01 + 2)
time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=0,
tm_min=0, tm_sec=2, tm_wday=6, tm_yday=1, tm_isdst=0)





-- Fio Cattaneo

Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."

On Tue, Jan 15, 2019 at 10:01 AM jimlux <jimlux at earthlink.net> wrote:
>
> 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.
>
>
> 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.
>
> 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.
>
>
> (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)
>
> _______________________________________________
> 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.