Blame | Last modification | View Log | RSS feed
Y2K compliance in libpng:=========================October 15, 1999Since the PNG Development group is an ad-hoc body, we can't makean official declaration.This is your unofficial assurance that libpng from version 0.71 andupward through 1.0.5 are Y2K compliant. It is my belief that earlierversions were also Y2K compliant.Libpng only has three year fields. One is a 2-byte unsigned integerthat will hold years up to 65535. The other two hold the date in textformat, and will hold years up to 9999.The integer is"png_uint_16 year" in png_time_struct.The strings are"png_charp time_buffer" in png_struct and"near_time_buffer", which is a local character string in png.c.There are seven time-related functions:png_convert_to_rfc_1123() in png.c(formerly png_convert_to_rfc_1152() in error)png_convert_from_struct_tm() in pngwrite.c, called in pngwrite.cpng_convert_from_time_t() in pngwrite.cpng_get_tIME() in pngget.cpng_handle_tIME() in pngrutil.c, called in pngread.cpng_set_tIME() in pngset.cpng_write_tIME() in pngwutil.c, called in pngwrite.cAll appear to handle dates properly in a Y2K environment. Thepng_convert_from_time_t() function calls gmtime() to convert from systemclock time, which returns (year - 1900), which we properly convert tothe full 4-digit year. There is a possibility that applications usinglibpng are not passing 4-digit years into the png_convert_to_rfc_1123()function, or that they are incorrectly passing only a 2-digit yearinstead of "year - 1900" into the png_convert_from_struct_tm() function,but this is not under our control. The libpng documentation has alwaysstated that it works with 4-digit years, and the APIs have beendocumented as such.The tIME chunk itself is also Y2K compliant. It uses a 2-byte unsignedinteger to hold the year, and can hold years as large as 65535.zlib, upon which libpng depends, is also Y2K compliant. It containsno date-related code.Glenn Randers-Pehrsonlibpng maintainerPNG Development Group