> First, the ISO9660 bug. The ISO file system driver in Linux doesn't
handle
> leap years correctly. It assumes all years divisible by 4 are leap
years,
> which is incorrect. For those that don't know the right algorithm, all
> years that (are divisible by 4) and ((not divisible by 100), or
(divisible
> by 400)) are leap years. ISO file dates on or after March 1, 2100
will be 1
> day off when viewed under Linux as a result. The bug is in
fs/isofs/util.c,
Ok, unless I'm missing something (quite possible), this bug cannot be
fixed without lots of changes outside fs/isofs/util.c .
First of all, the function returns "int", so ints being 4 bytes, this
function can not handle dates beyond ~2038. And since there are no leap
years between 1970 and 2038 that are not correctly accounted for by just
doing a divide by four (the year 2000 would have been the only exception
due to the if year%100 == 0 then it's not a leap year rule, but it is
after all due to the year%400 exception to that rule).
There is also the problem of the function only being passed a single
char as the value for the year - that's not enough to be able to pass
the year 2100, and it's only beyond this year that we have a problem
with the current code. In order to be able to pass more than a single
char to iso_date() we'd have to modify the "struct iso_directory_record"
structure to extend the "date" field to be able to hold the entire four
digit year that iso9660 actually stores on disk (if I'm not mistaken) -
changing that struct would then require that all users of the struct be
checked for correctness. That's quite a large piece of work, and it's
pointless as long as iso_date just returns "int".
Is the above analysis correct or did I miss something obvious?
If the above is indeed correct, wouldn't it then be better to just do
those changes in 2.5.x instead of 2.4.x (and then maybe backport them
later)...
Comments ?
Best regards,
Jesper Juhl
[email protected]
On Wed, 27 Feb 2002, Jesper Juhl wrote:
[SNIPPED year 2100 "bug"]
[SNIPPED year 2100 "bug" --fix!]
>
> If the above is indeed correct, wouldn't it then be better to just do
> those changes in 2.5.x instead of 2.4.x (and then maybe backport them
> later)...
I suggest the changes wait until Version 99.99. Many of the File Systems
affected won't even exist 98 years from now -and an 'int' will probably
be 256 bits.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
111,111,111 * 111,111,111 = 12,345,678,987,654,321
On Wed, 2002-02-27 at 15:29, Richard B. Johnson wrote:
> On Wed, 27 Feb 2002, Jesper Juhl wrote:
> [SNIPPED year 2100 "bug"]
> [SNIPPED year 2100 "bug" --fix!]
>
> >
> > If the above is indeed correct, wouldn't it then be better to just do
> > those changes in 2.5.x instead of 2.4.x (and then maybe backport them
> > later)...
>
> I suggest the changes wait until Version 99.99. Many of the File Systems
> affected won't even exist 98 years from now -and an 'int' will probably
> be 256 bits.
>
Sure ;) I'll just leave it alone for now. Maybe later if things change
it can be fixed without requireing major changes.
--
Mvh. / Best regards
Jesper Juhl - [email protected]