Re: [MacPerl] Time::localtime not Y2K.

[Joel Rees <joel_rees@sannet.ne.jp>]

For all the curious, there are several reasons we do not center our time 
keeping systems around the year 1 AD. 

Perhaps the biggest is that we really don't know when that year began. 
The historical and biblical records seem to match up best during the year 
we would calculate backwards with our present calendar as 3 BC, a little 
after vernal equinox, as I recall. Then there is the business of leap 
years being calculated incorrectly until Pope Gregory's reform. Our 
current calendar gets out of sync with history as we go back, so it's 
only useful (back then) for astronomical events taken independently of 
human history. It becomes useful for historical events around the year 
1693 or so, as the various countries of Europe adopted the Gregorian 
Calendar. And they did not all adopt it at the same time.

Then there is the other biggest reason, which is that 4,294,967,296 
seconds (the number of discrete values representable in 32 bits) is only 
about 135 years, and time_t is (still) usually defined as long. (The 
general long long type is only a recent innovation, longs are usually 32 
bits, and it feels kind of uncomfortable using doubles to count seconds 
in time_t.)

And of course the other biggest reason is that there are several 
competing calendars, like the Jewish and Chinese calendars.

So the C time.h library and Perl tell us about time in reference to some 
recent date, which the ANSI-C committee decided should be the year 1900. 
:-0 

And the proper handling of dates is supposed to adjust by adding 1900, at 
least for western culture. Other cultures will adjust it differently.

Some really old iron may have Y2K-type problems in about 35 to 37 years. 
(Put the present in perspective: G4==old iron? What will the world look 
like then? Will CPUs be fast enough to run the latest version of 
Windows's successor?)

joel_rees@sannet.ne.jp

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org