Two interesting messages from deep in Cupertino:
Today, 2006.01.27, marks an event that will happen only sixteen times, and not all of them in our lifetime.
If you've used a Macintosh for more than the past few years, then you've undoubtedly seen a strange date and time pop up in unexpected places. Novices wonder why "January 1, 1904 12:00 AM" seems to be so important to our strange little platform, the one that was built upon 1984's strange little computer. That date was more than 80 years before the computer was released, so realistically, it's neither a manufacturing date, nor an Easter egg for the birthday of a designer or "notoriously prickly" CEO.
After a while, those who care learn the story. The Macintosh was one of the first computers to carry a battery on its logic board to maintain critical data and functions even when the computer was powered off. The small battery powered the storage of 256 bytes of parameter RAM (PRAM ) that kept everything from your volume setting to your desktop pattern.
Remember, back in those days, there was no hard disk. You booted the Macintosh from a floppy disk. If you had to switch applications, more often than not you had to eject your boot disk and insert an application disk that also had a System file on it. The OS then "switched" to that active system file so it didn't keep asking you to swap floppies up to 75 times per application launch. Because there was no hard disk, there was no easy location to write system-wide preferences. The ones that Apple's engineers felt had to be available at all times were stored in the battery-backed PRAM.
If the battery lost power or you reset the parameter RAM as a troubleshooting tool, it lost all of its contents. Upon the next system startup, the firmware burned into the computer's ROM reset the PRAM to default values. The PRAM also stored the current date and time so it wouldn't be lost when you powered down, and the battery powered the chip that kept the time current. Therefore, if you removed the battery or even reset PRAM, your system date and time reset to the default value: 1904.01.01 at 12:00 AM.
But why this odd value? As it happens, it was chosen for completely nerdy reasons of technical excellence. The clock chip in the Macintosh was really just a simple timer that incremented a 32-bit counter once every second. In hexadecimal (base 16, 0-9 plus A-F as digits, useful to computers because it can express large binary values in compact form), the value could range from 0x00000000 to 0xFFFFFFFF (or, in decimal, from 0 to 4,294,967,295).
This number means something only when interpreted - it's a number of seconds, but from what point? The Mac OS designers wanted to encompass a wide range of potential date and time values, so they knew that "0" would have to mean a date several decades before 1984. They thought about choosing 1900.01.01 as a natural starting time, figuring not many people would need to use the operating system's date facility for any date before the last year of the 19th Century.
Yet that choice was slightly more complicated than it looked. Under the Gregorian calendar, years whose numbers are divisible by 4 are leap years, _unless_ they are also divisible by 100 but not 400. This corrected for the eventual realization that the earth revolves around the sun in 365.24 days, not the even 365.25 days that had been previously thought. (Britain and its colonies made the switch from the Julian to Gregorian systems in 1752, magically skipping ahead 11 days in that year, so that 1752.09.02 11:59 PM was immediately followed by 1752.09.14 12:00 AM. This came to light  recently in celebration of Ben Franklin's 300th birthday: Franklin was born on 1706.01.06 in the British colony of Pennsylvania, but the 300th anniversary of his birth was 2006.01.17 because of the 1752 date skip.)
If Apple's engineers started the clock on 1900.01.01, their algorithms for calculating dates and times to display would have required adjusting for the fact that 1900 was not a leap year. The clock chip's counter spans a range of 4,294,967,295 seconds, or a little over 136 years, so they would only have the problem of non-leap century years if they chose the base date poorly.
That's why they chose 1904.01.01 12:00 AM as the base time - the start of the first leap year of the 20th Century. By starting on a leap year, they saved something like a cycle or two in the time calculation, and saving time and ROM space was critical in 1984. The choice, however, meant that any uninitialized date and time value - a file saved with no time stamp, PRAM with default contents, and any other date value of zero - would display as "January 1, 1904 12:00 AM" by default (although, outside the US, your display format may vary).
That leads to the other end of the range. The last time period measurable by the 32-bit counter is the default date plus 0xFFFFFFFF seconds: Monday, 2040.02.06, at 6:28:15 AM. You may have seen references to "February 6, 2040" in some documentation that discusses date ranges that you can enter in contact managers or databases. Programs that use the original Mac OS date and time routines for storing times also use a 32-bit number of seconds, and because of that, you can't enter any date outside the range of 1904.01.01 to 2040.02.06. If you have an original Macintosh computer running on 2040.02.06 at 6:28:15 AM, then one second later, the computer will believe it is 1904.01.01 at 12:00 AM. The counter rolls over to zero, and zero means 1904.
Obviously, today is neither in 1904 or 2040, so what's the big deal? Humans like to celebrate anniversaries of round numbers - 10 years, 100 years, 1000 years, and so on. When we see a lot of zeroes at the end of a number, even a car's odometer turning over to 50,000 miles (or kilometers), we reflect on the past and future. It's human nature.
The round numbers for computers are all powers of two, but in hexadecimal, they have a lot of zeroes. Four gibibytes, the technical name for 2^32 bytes, is 0x100000000 bytes (since byte #1, to a computer, is the one numbered 0x00000000, the range is from there to 0xFFFFFFFF, but it's still 0x100000000 bytes, just like there are ten digits from zero to nine). One megabyte, or 2^20 bytes, is 0x100000 bytes, and so on.
For a given number of digits in base ten, there are ten values where all but the most significant digit is zero. In hexadecimal, there are sixteen such values for a given number of digits; for a 32-bit counter of seconds, the top-most digit changes every 0x10000000 seconds, or every 8 years, 26 weeks, 2 days, 22 hours, 54 minutes, and 7 seconds. The most significant hexadecimal digit of the Mac OS's date and time counter has been 0xB since the counter hit 0xB0000000 on 1997.07.26 at 7:26:56 PM.
Today that counter rolls over to another significant digit. On 2006.01.27, at 4:51:12 PM, the internal count of seconds reaches 0xC0000000. When the Macintosh was introduced in 1984, the most significant digit of the counter was already 9, so this is only the third such roll-over in the 22-year history of the platform. These are abstract times and are not affiliated with a time zone, so the raw value in any given current Macintosh model may vary, and the 4:51:12 PM figure is your local time. That's when the current date and time can't be expressed with anything less than 0xC0000000.
Geeky, to be sure, but a marking of the passage of time - and an excuse for an impromptu party. You're now in the C era. Apple long ago introduced new time routines than measure more than 29,000 years on either side of the year 0 C.E., so nothing's going to expire. Nothing's going to wear out, and nothing's going to stop working. But it's the passage of time, a moment to notice that a date that seemed so far in the future isn't as far away as it used to be. A heart beats only so many times in a life, and a seconds counter can only measure so far before it gives up and starts over.
Just pause tonight, or at 4:51:12 PM if it's not already passed in your local time, and remember how far we've come - and how far we have yet to go before we rest.
C0000000 11000000000000000000000000000000 YIPPEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!