ClassicHasClass
Well-known member
One of the bugs I fixed in Classilla 9.3.2 was an issue with cookies far in the future overflowing the 32-bit time value in the classic Mac OS. Interestingly, this value is unsigned, unlike the regular time_t in OS X, which is signed.
It is well-known that 32-bit time_t values have a Y2038 problem, because (counting from the Unix epoch start date of midnight 1 Jan 1970) the signed 32-bit quantity (thus 31 bits) will overflow on 19 January 2038 at 3:14:07am GMT. This is true of all 32-bit Mac OS X kernels as well, which includes 10.4, 10.5 and 32-bit 10.6, PPC or Intel, so every Power Mac running OS X and early Intel Macs will be affected. 64-bit OS X kernels use a 64-bit time_t and are not affected. You can prove this by looking at /usr/include/time.h, where time_t is defined as __darwin_time_t, and i386/_types.h and ppc/_types.h both define it as long (not long long). :scrambled:
You would expect that the classic Mac OS would be worse, because its epoch starts at midnight 1 Jan 1904. But because it has that extra bit of precision not used for the sign, it will overflow on ... 6 February 2040 at 6:28:15am local time. :cc:
Yes, that's right, Boy Scouts and others who wish to be prepared. You will survive the Y2038 apocalypse with the SE/30 you should recap and stick in your fallout shelter, or the MDD you have already reformatted and installed 9.2.2 on.
Now, the hacks part: it should be possible to write an extension to transparently handle this, at least for the menu bar clock. Programs that compute based on their own epoch assumptions would fail, but Classilla 194.38.2 will have this support.
See you in the bunker in 37 years. :rambo:
It is well-known that 32-bit time_t values have a Y2038 problem, because (counting from the Unix epoch start date of midnight 1 Jan 1970) the signed 32-bit quantity (thus 31 bits) will overflow on 19 January 2038 at 3:14:07am GMT. This is true of all 32-bit Mac OS X kernels as well, which includes 10.4, 10.5 and 32-bit 10.6, PPC or Intel, so every Power Mac running OS X and early Intel Macs will be affected. 64-bit OS X kernels use a 64-bit time_t and are not affected. You can prove this by looking at /usr/include/time.h, where time_t is defined as __darwin_time_t, and i386/_types.h and ppc/_types.h both define it as long (not long long). :scrambled:
You would expect that the classic Mac OS would be worse, because its epoch starts at midnight 1 Jan 1904. But because it has that extra bit of precision not used for the sign, it will overflow on ... 6 February 2040 at 6:28:15am local time. :cc:
Yes, that's right, Boy Scouts and others who wish to be prepared. You will survive the Y2038 apocalypse with the SE/30 you should recap and stick in your fallout shelter, or the MDD you have already reformatted and installed 9.2.2 on.
Now, the hacks part: it should be possible to write an extension to transparently handle this, at least for the menu bar clock. Programs that compute based on their own epoch assumptions would fail, but Classilla 194.38.2 will have this support.
See you in the bunker in 37 years. :rambo: