98N/A Y2K compliance in libpng:
98N/A =========================
98N/A Since the PNG Development group is an ad-hoc body, we can't make
98N/A an official declaration.
98N/A This is your unofficial assurance that libpng from version 0.71 and
98N/A upward through 1.2.8 are Y2K compliant. It is my belief that earlier
98N/A versions were also Y2K compliant.
98N/A Libpng only has three year fields. One is a 2-byte unsigned integer
98N/A that will hold years up to 65535. The other two hold the date in text
98N/A format, and will hold years up to 9999.
98N/A "png_uint_16 year" in png_time_struct.
98N/A "png_charp time_buffer" in png_struct and
98N/A "near_time_buffer", which is a local character string in
png.c. 98N/A There are seven time-related functions:
98N/A (formerly png_convert_to_rfc_1152() in error)
493N/A All appear to handle dates properly in a Y2K environment. The
98N/A png_convert_from_time_t() function calls gmtime() to convert from system
98N/A clock time, which returns (year - 1900), which we properly convert to
493N/A the full 4-digit year. There is a possibility that applications using
98N/A libpng are not passing 4-digit years into the png_convert_to_rfc_1123()
98N/A function, or that they are incorrectly passing only a 2-digit year
98N/A instead of "year - 1900" into the png_convert_from_struct_tm() function,
98N/A but this is not under our control. The libpng documentation has always
98N/A stated that it works with 4-digit years, and the APIs have been
98N/A documented as such.
The tIME chunk itself is also Y2K compliant. It uses a 2-byte unsigned
integer to hold the year, and can hold years as large as 65535.
zlib, upon which libpng depends, is also Y2K compliant. It contains