AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
June 1999

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



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

Scott Lasica writes,


> Hello,
>
> I'm trying to find any "official" statements on Y2K compliance for both Tiff
> and GeoTiff.  Does anyone know of such a document?
>
> Scott J. Lasica
> Technical Lead Software Engineer
> Research Systems Inc.
> IDL/ENVI/RiverTools
> http://www.rsinc.com
> slasica@rsinc.com
>

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.