[time-nuts] How best to compute local time from GPS

[Bruce Griffiths]

Magnus Danielson wrote:
>> Quoth David Forbes at 2008-03-25 13:37...
>> ...
>>     
>>> 2. If I have to store the time zone from the user's input, are the 
>>> DST calculations reasonably straightforward these days?
>>>
>>> 3. What weird time zone operations should it support, such as 15 
>>> minute local offsets or oddball DST dates?
>>>       
>> The problem with coding this stuff into your software is that it will be 
>> out of date no sooner have you hit 'compile'.  Whilst it would be cool 
>> to use the Zoneinfo database <http://en.wikipedia.org/wiki/Zoneinfo>, 
>> it's quite big (about half a Meg, IIRC) and would also require network 
>> access.
>>
>> I'd be inclined to convert GPS time to UTC and then let the user set 
>> through the menu system their UCT offset in hours and minutes (I live in 
>> one of the daft half-hour timezones) and also DST start/end dates.  This 
>> gives you complete flexibility - which is required when the authorities 
>> keep messing around with their daylight-saving plans.
>>     
>
> I had the same thought, but with a twist. But first the general comment.
> You would have a hell to figure out what country and part of country you are in
> from GPS position since that would require you a digitized zone-map and then a
> region-to-offset and DST table. As for DST, they change... US just changed for
> instance. Europe coordinated back in 2001 to common DST times. DST dates you
> must assume to be different wherever you go an the US have proved them to be a
> variable even today. 
Political boundaries can also change.
For example the Ethiopia/Eritrea border location hasnt yet been settled, 
although a proposal has been formulated for adoption.
NZ also changed the date for reverting from summertime, starting this year.
> As for offsets, to be fullblown generic, you need 15 min
> offsets. Actually, you would even require to support UT1 and UTC if you would
> support things correctly. Then we have those nations running solar time
> directly and then we have solar time, i.e. time of day from sun rise.
>
>   
Supporting UT1 to an accuracy of much better than 1sec is a little 
problematic unless one decodes the appropriate CNAV packet broadcast on L2C.
Unfortunately this isnt possible when using a legacy L1 only GPS receiver.
Alternatively one can download UT1-UTC predictions and adjust the stored 
offset as and when required.
At the moment UTC is kept within 0.9sec of UT1 by the leapsecond mechanism.
If and when leapseconds are done away with calculating UT1 to the same 
accuracy becomes problematic without the UT1-UTC correction broadcast on 
L2C or IERTS UT1-UTC predictions..
> It's a mess. Recent events is making it a bigger mess. Choose to support UTC
> plus an UTC offset and another UTC offset between certain dates. Now for the
> twist. Let a little computer software on the side aid in setting this thing up.
> You can evolve that from a direct question application to one that does more
> and more complex analysis... when you feel like it, and without creating a
> heavier code in the scopeclock. 
>
>   
>> Anyone who hasn't seen David's scope clock stuff, it's seriously cool.
>>     
>
> I have an AVRclock, how do they compare?
>
> Cheers,
> Magnus
>   
Bruce