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

[Mike S]

At 11:07 PM 3/24/2008, David Forbes wrote...
>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?
>
>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.)

There is a well accepted method of specifying time zone offset and 
summer time adjustments. It is much simpler than trying to parse an 
Olson timezone table (which has historical information to allow date 
and calculations, something not needed for a clock). It allows for the 
full range of rules, and you don't have to worry about updating a table 
should the rules change. This is called a IEEE 1003.1 POSIX timezone 
literal. A good description is contained in 
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-tz-00

To specify the timezone for the eastern US, including current daylight 
saving time rules, one would use 
TZ="EST5EDT4,M3.2.0/02:00:00,M11.1.0/02:00:00"


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [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 , 
>> 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

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Magnus Danielson]

From: Matthew Smith <[EMAIL PROTECTED]>
Subject: Re: [time-nuts] How best to compute local time from GPS
Date: Tue, 25 Mar 2008 14:11:36 +1030
Message-ID: <[EMAIL PROTECTED]>

> 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. 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.

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

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Morris Odell]

David Forbes asked:

>> 2. If I have to store the time zone from the user's input, are the
>> DST calculations reasonably straightforward these days?

It's not too difficult and you get a nice refresher in modulo-7 arithmetic. 
I did it in AVR assembler recently although I didn't try to make it 
universal. Our government down here in south-eastern Australia recently 
changed the DST changeover dates so I customised it for where I live. If you 
need to make it user settable that would mean you need to be able to enter 
the dates and UTC offsets as a menu item which would complicate things 
considerably. It'd be a fun programming challenge though :-)

>> 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.)

I put a 3 position (centre off) switch on the back panel of my clock. The 3 
positions are: Summer time, Auto, Winter time. That way after I'm demented 
or dead and gone if the gov't changes the rules again it can be changed 
manually.

I programmed the receiver for our local time offset from UTC. I then add or 
don't add an hour as the case may be.

Morris 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Hal Murray]

> 1 Is there a reasonable way to determine the local time zone from the
> GPS sentences? 

None that I know of.

But given that you have GPS you probably know where you are.  If you had a 
map of the globe with the time zone boundaries drawn on it, you should be 
able to figure out which zone you are currently in.

That sounds like a fun project.  I'll bet somebody has done it.  Try google.

It would be fun to watch it tick over as you drove across the line.  (and 
watch it stutter if you could find a road that went along the boundary)


> 2. If I have to store the time zone from the user's input, are the
> DST calculations reasonably straightforward these days? 

It is pretty easy if you are willing to call a subroutine and have space for 
that routine and it's data.

The typical programming environments for everything bigger than a tiny system 
includes the time conversion routines in libc and an extensive collection of 
time zone tables.

The user input is to pick your time zone from a big list.  There are several 
versions of the tables.  I haven't kept up with why they forked.  On my 
system, one set has 547 entries.  (There are probably many duplicates in 
there.)  There are 12 in the US subdirectory, 53 in Europe.  They are roughly 
1K each.

I'd start with the man pages for strftime, ctime, and friends.  google will 
find copies if you don't have a *nix system handy.


> 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.) 

DST is covered by the above mentioned package.

You need to install a new set of tables whenever Congress changes the rules.


I haven't looked at any of the modern timezone tables.  Many years ago, I was 
looking at the Tenex time conversion code.  There was a big comment at the 
top claiming that it did everything.  There was a small footnote saying that 
it didn't handle war time.


The wiki page that Matthew Smith mentioned looks good to me.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Bruce Griffiths]

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

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[Matthew Smith]

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 , 
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.

Anyone who hasn't seen David's scope clock stuff, it's seriously cool.

Cheers

M

-- 
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.