[time-nuts] GPS seconds conversion on an Arduino

Tim Shoppa tshoppa at gmail.com
Tue May 16 06:29:26 EDT 2017

Since future leap seconds aren't known very far in advance, how wise is it
to even claim to handle any possible leap second or time scale conversion,
in a firmware-controlled device that cannot download future leap second
information from the Internet?

The GPS itself presumably knows how to handle leap seconds at the moment
with possibly minor glitches.

If you can connect to the Internet, then I think you're good for maybe the
next few decades until the current concepts of "web" and "URL" and
"internet" become as hopelessly outdated as Telex addresses. I think the
URL concept probably has at least a decade left in it, and that's
considerably longer than the couple-times-a-year possibility of a leap
second, so leap second file downloads from IETF would seem to make sense if
you claim to handle such conversions.

The "future-proofing" of your time conversion is not a new issue. When I
read century-old articles about gear ratios for converting solar to
sidereal time (*) , they note that you should not try to get too many
digits of precision because they knew that the length of the solar day had
real and unpredictable variances even back then. One author notes that if
you want your gear ratio to work well for the next 100 years, you should
use the ratio appropriate for 50 years into the future, not today.

Now admittedly, microcontrollers generally don't last as long as a set of
gears :-)


On Sat, May 13, 2017 at 9:58 PM, Mark Sims <holrum at hotmail.com> wrote:

> Converting GPS seconds to Gregorian date/time on the Arduino will be an
> arduous task.  You take GPS seconds and add it to the GPS starring epoch to
> get a Julian date.  Then add in the number of leap seconds as a fraction of
> a day to get UTC and possibly add in a time zone offset for local time.
> Don't forget to do daylight savings time conversion...  Then convert the
> result to Gregorian date/time for display.
> The problem is the Arduino floating point library is single precision only
> and does not have the resolution needed to handle the numbers involved.
> Doing it with integer arithmetic (long longs) opens up a whole new can of
> worms.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list