[log in to unmask] wrote:
> [log in to unmask] wrote:
> >The C programming language has standard libraries for converting
> >time in secs since 1970 to date, and vice-versa. The file structures
> >usually have the "time last accessed" as this 32-bit number.
> >to a 64-bit compiler is great, but your OS and file
> structure might be
> >still affected.
> >So this affects only C and Unix, Right? Alas no, it affects a lot of
> >Operating Systems that have C components. Like Windows 95, 98,
> >NT, and I think 2000, also Win 3.11, in fact, a significant
> >of the world's computers. Of Macs I know not, but it
> wouldn't surprise
> >me if they had the same problem on some versions of their OS's,
> >especially the ones with significant bits of Unix in them (via Next).
> The Macintosh calling interface provides for the expression
> of tens of thousands of years. What they do internally is
> something they might have to fix some time, but that is
> rather easier than making users change.
For what it's worth, the information about Windows in the original message
is incorrect. The Win32 API returns times as a structure (record) with a
16-bit year number. The Windows documentation says that year numbers from
1601 to 2399 are guaranteed to work, and years outside of that might work.
Of course, Windows has C code internally, so it is possible that there would
be a bug in the OS, but I would expect that be fixed in Windows 2037 :-).
But Ada programs would still continue to work.
I actually had experience with this, as the BIOS on one of our Windows NT
servers became convinced that it was 2099 in January. Both the OS and the
custom written, all Ada mail management service ran properly; and the Ada
program logged the year as 2099 in its log files. Some other services
crashed, however, possibly because of their C heritage.