The year 2000 problem is relevant for mtools because of dates on files, both on the Dos side, and on the Unix side. Dates should be interpreted and represented correctly. AFAIK, this is the only relevance. Hence I performed the following simple tests to check out year 2000 readyness. Each test example involves 4 steps:
touch command
mdir to check whether the date is correct
ls to check whether the date is still good
|
As you can see, mtools handles dates beyond 2000 all right. However, while it is not affected by the year 2000 problems, it is unfortunately affected by the year 2038 problem (Unix dates roll over at the 19 of January 2038). However, as this later problem is tied to the 32 bit storage size of current Unix dates, the problem will likely have disappeared on its own by then.
> Here is the specific information that I need. > >1) Version number and/or distribution date of year 2000 ready software
These tests were performed using mtools-3.8, released on August 7th, 1997. All later versions are ok as well. Indeed, none of the recent changes involved this issue.
These tests were performed on Linux-2.1.59, and the version of 'touch' and 'ls' used were: touch (GNU fileutils) 3.15
Earlyer versions of touch may, (or may not) have Y2K problems, which would make testing difficult (although the problem would not be due to mtools).
The C library used was libc.so.5.4.38. This is relevant, as the localtime() function of the libc is used to translate dates from Unix to Dos. Very old libc's could conceivably have problems here. Libc's on Unices other than Linux could have problems too.
>2) Source address of year 2000 ready softwareMtools can be obtained from the following adress:
N.B. When 3.9.4 will come out, 3.9.3 will be removed.
>3) Status of software regarding the year 2000 software readiness criteriaAs seen above, mtools is ok between 1/1/1980 and 1/18/2038
>4) Strategy and /or schedule to reach year 2000 readiness, if not yet >completed
Year 2000 readiness is available now. Moreover, as soon as 64 bit dates will be in general use in Linux, year 2038 readiness will be tested and any occuring bugs corrected.
>5) Source address and cost (if any) of replacement product or recommended >replacement productNo replacement is needed for mtools to address year 2000 compliancy.
>1) Unambiguous date and century recognition before, on, and after January >1, 2000
Mtools dates are ok between 1/1/1980 and 1/18/2038. Dates before 1/1/1980 do not make sense for mtools, as DOS was not around back then. The 2038 limit will probably go away by itself as soon as 64 bit computers will be mainstream, which will probably happen long before 2038.
>2) Calculations to accommodate same century and multi-century formulas and >date valuesNot applicable, as mtools does not calculate any date differences.
>3) Date data interface values that reflect the century
During the applicable range of dates (1/1/1980 to 1/18/2038) the century is displayed.
>4) Year 2000 must be recognized as a leap year and handled as such in any >calculations
Actually, the year 2000 is rather programmer-friendly, as no exception from the usual rule ("all years divisible by 4...") is needed. Interesting problems will happen in 2100 though...
|
>5) Date related calculations must not result in system failuresNone of the dates that I tried crashed mtools, nor the OS.
If you need any additional tests that are not covered in this file, or if you think that any of the points I marked "non applicable" are relevant anyways, don't hesitate to contact me.
|
|