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

Bruce Griffiths bruce.griffiths at xtra.co.nz
Tue Mar 25 03:45:34 UTC 2008


David Forbes wrote:
> O Time Nuts,
>
> I am working feverishly on the software for my new scope clock. This 
> is a circuit board that drives a 3" oscilloscope tube with a rather 
> good-looking display of numbers and letters, driven by an HC908 MPU 
> and a hardware circle-drawing engine. The basic gizmo is shown here:
>
> http://www.cathodecorner.com/sc200c.html
>
> I am writing because I am now coding the GPS receiver interface. I 
> realize that GPS time is not the same as either UTC or local time, 
> and I am trying to figure out the best way to deal with this fact.
>
> I have provided a user interface to the clock consisting of a rotary 
> encoder with built-in pushbutton. This controls a menu stack that 
> functions well and is quite extensible.
>
> I am using a little Garmin GPS 18 LVC puck receiver, chosen for its 
> reasonable cost and 1PPS output. I designed the DE9 serial port 
> connector with extra pins to drive current-limited 5V to the puck and 
> to receive 1PPS to the CPU's IRQ line.
>
> I have written code to buffer up and parse the GPRMC sentence that 
> gives time and date and location. Now I need to figure out what to do 
> with these numbers.
>
> I prefer to have the clock run on GPS or UTC time, then convert to 
> local time as it displays the time. This makes the code more logical 
> to write, since everything flows from GPS time.
>
> So...
>
> 1 Is there a reasonable way to determine the local time zone from the 
> GPS sentences?
>
>   
The GPS receiver will only provide the users longitude and latitude from 
which you can, in principle, determine the time zone.
However this probably requires coding the complex shape of the various 
timezone boundaries.
> 2. If I have to store the time zone from the user's input, are the 
> DST calculations reasonably straightforward these days?
>   
Depends where you live. Politicians continue to tinker with the 
changeover dates and time zones.
> 3. What weird time zone operations should it support, such as 15 
> minute local offsets or oddball DST dates?
>
> 4. In general, is it better to let the user turn DST on and off or 
> try to do it automatically? (I live in Arizona, which doesn't worship 
> DST, so I have no experience in this matter.)
>
>   
Depends on the user, providing both options would allow manual 
compensation for DST transition date changes until a firmware upgrade 
were available.

Having the user to set the transition dates, times and associated 
offsets from UTC would be more flexible and reduce the support burden 
given the propensity of politicians to tinker.
This only need be done once (at a given location) and would only require 
changing when the clocks timezone changed.
If a serial port (could share the same port as the GPS receiver, 
switching between the GPS receiver and the user configuration data 
source as required) were provided to allow user configuration this may 
be easy to do using a terminal emulator running on a PC.
> 5. Considering that the source code is being provided with the clock, 
> are any of you fine folks interested in getting one of these gadgets 
> to see what you can do with it?
>
> I await your reasoned replies.
>   

Bruce




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