> What's the GPS week-rollover? I've heard of some of the other dates, but
>this is the first I've heard of a GPS issue.
GPS weeks are represented in, I think, ten bits. Itīs in the spec, but
evidently a lot of people overlooked it when designing their almanac
functions. Week Zero will begin on Sunday, 22 August (Zulu - GMT - time).
No system in the field today has dealt with a Zero week before, because the
test environment - brassboard - systems were airborne at that time. They
didnīt start the clock over again with the first satellite launches. You
can buy emulators that feed fake satellite signals to a receiver for test
purposes. The GPS Joint office ground station was designed with this in
mind, but I guess they have Y2K issues theyīre still working on related to
other parts of system operation (they have until 12/31/99 to fix those).
>> I think 2038 is the UNIX date rollover.
>
> Yep; Its a software issue brought on by the hardware. The problem here
>is that the standard Unix time libraries store date and time as the number of
>seconds since the epoch (sp?) I believe that is January 1, 1970, GMT. At
>any
>rate, as the dates get further from 1/1/70, this number gets bigger and
>bigger.
>With the current 32 bit machines, the largest integer they can store is
>2,147,483,647. (That's January 19, 2038 (at about 3:15am) GMT. If you try
>to add one to that number, it will probably will roll over to 0, butI
>believe its
>pretty much undefined.)
Many implementations would actually roll over to minus one (-1), the next
twoīs-complement number.
>Some unix systems use a bigger data type (long instead of int)
>for this variable, so they're immune. At any rate, as long as we aren't
>using 32 bit systems in 2038, we'll be OK. Systems like the DEC Alpha
>don't have to
>worry about this particular problem for a very long time. :-) (Because their
>integers are 64 bits instead of 32, so (if my calcs are right) they won't
>experience
>this problem until the year 292057780204). I wonder if my Dak will still
>be around
>then? :-)
You need to be running a Y2K-compatible 64-bit version of the OS, which
Sun, SGI, and DEC/Compaq have all released. There are patches available for
most recent OS releases too. Otherwise, your 64-bit machine (generally
capable of 128-bit math), will be running the code in the time libraries in
compatibility mode. Answers arenīt guaranteed to be the same as a 32-bit
machine would come up with, but itīs not likely to be correct. And almost
all of the commercial libraries had bugs that WILL have problems with 2000.
There are patches, as I said.
BTW, DECīs VMS has always used a 64-bit integer for time, but time was in
10 microsecond ticks, which will run out a bit before four digits is no
longer enough for dates... Sameīs true for Macintoshes, which I think are
okay until something like 2200. MacOS can handle 2000 fine, but I expect a
few Mac applications wonīt be happy-happy-joy-joy.
Jim
ī93 4x4 CC V8
This archive was generated by hypermail 2b29 : Fri Jun 20 2003 - 12:11:53 EDT