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

Fiorenzo Cattaneo fio at cattaneo.us
Tue Jan 15 20:33:48 UTC 2019


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 mentioned in the writeup) POSIX requires a day
length to be 86400 *AND* requires to be UTC. These two requirements
are fundamentally at odds with each other, which is why it's so
complicated to deal with this in general purpose code.




-- Fio Cattaneo

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

On Tue, Jan 15, 2019 at 12:25 PM Fiorenzo Cattaneo <fio at cattaneo.us> wrote:
>
> 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.




More information about the Time-nuts_lists.febo.com mailing list