Has anyone yet attacked the issue with the year 2040 problem? The issue as I understand it is that the API assumes a 138 year range from January 1st 1904 through Febuary 6th, 2040, this is one place where Apple was a bit short sighted. This is do to using a 32-bit count of seconds.
If it has not been attacked yet, I would like to propose that those that are hacking on the system implement a new API (as old programs are tied to the problem) that provides a 32-bit day value (11.7 million year range) with a separate 32-bit field for centaseconds into the day. I am not sure how we could shoehorn this into the HFS+ filesystem, though I am sure someone here has a good idea of how to do this, and I think that going for 11.7 million years should keep future Mac OS 7/8/9 users quite happy for at least two-hundred-thousand generations before the limit is reached. There are eighty-six-thousand-four-hundred seconds in a day (86400 seconds in one day), which is 8640000 centaseconds taking 24 bits. If the unused 8 bits were applied to the day count we could go for 2.9 Billion Years, though it is likely better to use those 8 bits for something else.
I figure as there are still new Classic Macintosh users in the youngest generation, do to the features and simple usage of the systems, this should continue for at least a few more generations, so may as well make sure we can timestamp for a long enough period to never need to worry about it again in the lifespan of the species as a whole.
Another concept for the short term (give us time to design a new FS to get around the issues) would be to take the years in the clock from 1904 through 1980 and treat them as being from 2041 through 2117, that buys us an extra 77 years to play with before we need a new date format without question.
Topic: Correcting the Year 2040 Problem? (Read 2038 times)