On Wed, May 6, 2015 at 6:48 AM, Mark Sims <[email protected]> wrote: > Well, a big one will be in 2017 when all our Tbolts roll over. I have > included some code in the next version of Lady Heather to compensate. If it > detects a year from the unit before 2015, it converts the date/time to > Julian, adds 1024 weeks worth of seconds, and then converts the date/time > back to Gregorian. You can also specify a user defined rollover adjustment > (in seconds). One issue that I have seen is the Tbolt occasionally spitting > out a bogo-year and triggering a false/premature rollover... still trying to > track that down. > > People using Tbolts for things like NTP servers will have to implement a > similar fix...
I assume the Tbolt rollover will be problematic for those who start their Tbolt completely cold (no time, almanac, or ephemeris) and without any non-GPS input, but how will the Tbolt behave in situations where the user initializes the Tbolt with the then-correct post-rollover date and time? For example, one might use Tboltmon and a wristwatch to set the approximate time on the unit and then let it figure out the precise time from GPS. Also, will the rollover cause time-of-day problems for running Tbolts? That is, would they "ride through" the rollover and continue to provide the correct date and time as expected (that is, they recognize that a rollover occurred and keep working normally so long as they're not cold-reset) or would they immediately jump back to December 14, 1997 (the Thunderbolt "zero" date)? According to <https://www.febo.com/pipermail/time-nuts/2014-September/086664.html> it looks like they'll output the incorrect date as they cross over the rollover point. That's not good. -- Pete Stephenson _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
