1999.06.24 04:30 "Re:Y2K compliance statement?", by Niles Ritter

I'm trying to find any "official" statements on Y2K compliance for both Tiff and GeoTiff. Does anyone know of such a document?

I suspect you won't find anyone willing to write such a thing on an official level, since most warranties involve purchased software.

In either case, the TIFF spec only deals with time-dependencies in the "DateTime" tag, denoting when the image was created. The format of that tag is in ASCII text, and always uses a four-digit year, so it is pretty much immune to Y2K issues as such. When the year 10000 rolls around there will be hell to pay, though... The only thing one can fault the DateTime stamp about is that there is no way to indicate what time zone the date-time refers to, and does not support time resolutions higher than one second intervals. For this reason, usage in remote sensing ephemeris is limited.

The GeoTIFF spec does not refer to any date/time properties beyond those of the TIFF scope, and so is probably Y2K safe.

So far we're just talking about specifications. Now about the public domain "libtiff" package:

Regarding the "libs", since these are link-libraries there is no guarantee that a program that links them in will not have Y2K problems elsewhere. The libraries themselves look clean, since the datetime string is not parsed.

There are several programs in the "tools" section that use the <time.h> functions to get the current date-time, which do not have any 2000ce issues, but have the same problem of any program using the 32-bit unix clock, which wraps around somewhere in the 2020's or 30's.

Enough said about that.

--Niles.