> I haven't been following this too closely up to this point but the problem
> isn't with the Date & Time control panel. It is the case that the internal
> Mac clock cannot handle dates past 2040. I wrote a program two years ago to
> demonstrate this. True there are routines in the OS that allow Mac programs
> to handle dates past 2040, but the Mac OS is not one of those programs that
> use these routines. Really the problem isn't as easy as switching API's. The
> Mac OS could have been updated in a way that would have used the new
> routines long ago. For some reason or another that never happened. It most
> definitely is not a range check issue with the Date & Time Control Panel.
> The internal Mac clock stores time in the format of the number of seconds
> since midnight 1/1/1904. It stores this date in a 32 bit integer. This
> integer will roll over, if I recall correctly, late Feb 2040.
While the hardware clock is an issue, it is not the same issue as we are
discussing. Basically, the clock issue affects the machine at startup, when
the current date and time are set. However, that does not affect the range
of representable dates and valid dates for manipulation, which is largely
governed by the data structures and functions for manipulating and storing
those data structures.
With regard to the hardware clock, clearly, the interpretation of the
starting point of the hardware clock will need to be changed as time
progresses, as has already been done for OS X.
Just to summarize to this point:
1. The Mac OS from at least version 8 has have the capability to properly
store, manipulate, and display a range of approximately 60,000 years
centered on the Christian date A.D. 1. There also exists an older API which
is restricted to no later than 2040 which is still in use.
2. Date & Time control panel does not allow the current time to be set past
2040, which up to OS X matched the limitations of the range of the hardware
clock, which can count approximately 130 years.
3. The hardware clock limitation is partially resolved in OS X by changing
the reference point from 1904 to a later date which I do not recall.
4. The hardware clock is an issue only if the current time crosses the
boundary of the clock's representation limit (as was the case with many
systems, but not Macs, in 2000). [Or if the system is set so that its
"current time" crosses this boundary.]
5. An amazing number of application developers seem to have forgotten (or
perhaps never learned) that the "Year 2000 problem" was actually a
combination of three completely separate but related problems: a) hardware
clock time representation limitations, b) data structure limitations, & c)
date manipulation algorithm assumptions.
6. A depressingly large number of allegedly competent Macintosh application
developers are not familiar with the current MacOS APIs, technotes,
guidelines, and recommendations. (This is no surprise considering the dismal
quality of most "computer science" curricula, and the complete absence of
any proper engineering in such curricula).
--
Eric Hildum
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
To search the archives:
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
