Subject: [NEXTEL-1] More on GPS time and i88

From: Marcel <[email-masked]>
Date: Fri, 20 Dec 2002 01:59:03 -0500

-------- Original Message --------
From: Jliss-Viewsonics <[email-masked]>
Subject: More on GPS time and i88

OK. I've tested the getTimeStamp() method and it reports back GPS time as
milli seconds since 01-jan-1970 00:00:00, i.e., standard Unix time format.
This is problematic as GPS time is not the same as GMT (or UTC for that
matter). And as of 23:59:47 UTC on 21 August 1999 (GPS week-second reset to
0) is different by more than 13 seconds
I don't have any idea what you mean by Network time. The Internet runs on
UTC Unix time (Not really GMT which is civil astonomical time and can vary
up to almost 1 second from UTC). There is no local time or timezone other
than UTC on WANs. This allows synchronization across the network. The phone
service providers servers could be anywhere, serving many TimeZones and the
servers own TimeZone setting is useless for determining phone TimeZone.
Ideally the phone's timezone could be set via the Cell Tower in use by the
phone but I know of no provider that does this. Virtually every test I have
done with J2ME phones has reported the local time correctly (as set by the
tower) but GMT as TimeZone. I'm afraid the TimeZone will have to be set by
the phone user and saved or stored by the software provider in the JAD.
jerome
[email-masked]
tel.: 215-635-3980
fax.: 215-635-1088

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: Dave Emery <[email-masked]>
Date: Fri, 20 Dec 2002 21:46:59 -0500

> milli seconds since 01-jan-1970 00:00:00, i.e., standard Unix time format.

	If you had said seconds you would be right.   Unix time is
is in seconds and microseconds or nanoseconds depending on which
kernel you are dealing with.

> 0) is different by more than 13 seconds

	GPS time is monotonic (no leap seconds or any other corrections
used since GPS week 0.)   UTC (universal coordinated time) is adjusted
every six months to make it agree as best as possible with astronomical
time (so the sun rises and sets at the correct time and stars are in
the right positions at the right hour).  This is done with leap seconds
as needed.

	Both UTC and GPS time are based on the length of a second as
determined by a defined number of cycles of certain atomic resonances.
I think the current defination is based on the transistion between two
hyperfine levels of excited cesium atoms, but there is also a hydrogen
based standard in use and I would have to look up which is currently
considered the official defination.

	The number of cycles of the atomic resonance that make up a
second was chosen to match the mean rotation rate of the earth some
years back, and the earth is actually slowing down so almost every
year a leap second gets added to UTC to keep it in sync with the
stars.

	GPS time was made monotonic becuase it greatly simplifies
the navigation and timekeeping function if it never has to deal with
jumps in time.   And the jumps are unpredictable in advance since the
rate of slowing of the earth depends on weather and the influence of
the sun.

	The GPS satellites broadcast the correction between GPS time
and UTC in the almanac messages so a GPS receiver can report the correct
UTC without having to know the correction in the future.

> up to almost 1 second from UTC).

	This is nonsense.   Virtually everything in the world that cares
about serious timekeeping (most of the modern world) runs on UTC.  There
is no such thing as Internet time - the closest anything comes is UTC.

	And indeed true astronomical time based on the positions of the
stars can be off from UTC by up to a second and is always off by a little
bit.   This is mostly of interest to astronomers, however, not anyone
seeking to time events on earth.   If you are pointing a telescope you
care, otherwise not.

> There is no local time or timezone other
> than UTC on WANs. This allows synchronization across the network.

	By custom most people use UTC as it makes life easier since
it is invarient across the globe and users do not need to worry
about what time zone they are in or whether daylight savings is in effect.

	But on any particular WAN users could use local time if it made
sense - there is no fundemental reason other than custom for use of
UTC.

	And in a few places (the middle east in particular) religious
edicts (Islam) require that local time be set to astronomical time
rather than to a time zone time.   This results in bizzare clock offsets
in certain cities and places where the time is 1/2 hour out from everywhere
else.

> The phone

	Damned right.

> phone but I know of no provider that does this.

	My CDMA Verizon phone keeps local EST just fine.  And its gets
set by the network.  I suspect most all cellphones get set to local
time by the network.  Nextel is the same I am sure.  Most ordinary people
don't understand or want to use GMT.

	But a Java applet might want to know GMT as well.  Ideally there
should be classes that return both...

-- 
	Dave Emery N1PRE,  [email-masked]  DIE Consulting, Weston, Mass. 
PGP fingerprint = 2047/4D7B08D1 DE 6E E1 CC 1F 1D 96 E2  5D 27 BD B0 24 88 C3 18