Received: by smtp02.oce.nl (4.1/SMI-4.1)
	id AA09789; Thu, 24 Jun 99 06:31:26 +0200
Received: from gate7.olympiakos.com ([207.113.13.68])
	by oce.nl (8.9.0/8.9.0) with ESMTP id GAA16972;
	Thu, 24 Jun 1999 06:26:43 +0200 (MET DST)
Received: from localhost (bin@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id AAA31901;
	Thu, 24 Jun 1999 00:25:29 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Thu, 24 Jun 1999 00:24:50 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) id AAA31888
	for tiff-outgoing; Thu, 24 Jun 1999 00:24:49 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50])
	by gate7.olympiakos.com (8.8.7/8.8.7) with ESMTP id AAA31885
	for <tiff@olympiakos.com>; Thu, 24 Jun 1999 00:24:46 -0400
Received: from earthlink.net (pool010-max11.ds19-ca-us.dialup.earthlink.net [209.179.15.110])
	by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id VAA29067
	for <tiff@olympiakos.com>; Wed, 23 Jun 1999 21:24:42 -0700 (PDT)
Message-Id: <3771B474.44A28D81@earthlink.net>
Date: Thu, 24 Jun 1999 04:30:44 +0000
From: Niles Ritter <ritter@earthlink.net>
X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
Mime-Version: 1.0
To: TIFF Mailing List <tiff@olympiakos.com>
Subject: Re:Y2K compliance statement?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tiff@olympiakos.com

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.



