Y2KINFO revision f9a51917495bc8ba8b60632219652a7b122c1190
9174efb969475801d0dc88eee35aae40c748d450nd Y2K compliance in libpng:
ec79b29695b183f794264bbb578c51e93d1f9b1emartin =========================
ee508128c414648982d1cca7801f63b01a0a4f8aminfrin December 3, 2004
a623efbff95aab78da9e030524b0fa69b054f6d0brianp Since the PNG Development group is an ad-hoc body, we can't make
a623efbff95aab78da9e030524b0fa69b054f6d0brianp an official declaration.
a623efbff95aab78da9e030524b0fa69b054f6d0brianp This is your unofficial assurance that libpng from version 0.71 and
a623efbff95aab78da9e030524b0fa69b054f6d0brianp upward through 1.2.8 are Y2K compliant. It is my belief that earlier
0b4b04d8621478ba59f0a6ba2950ddc02ab92b58colm versions were also Y2K compliant.
0b4b04d8621478ba59f0a6ba2950ddc02ab92b58colm Libpng only has three year fields. One is a 2-byte unsigned integer
2f1bb5376c5c4022383bb729679ca751dd75a2eabrianp that will hold years up to 65535. The other two hold the date in text
2f1bb5376c5c4022383bb729679ca751dd75a2eabrianp format, and will hold years up to 9999.
ad862ab5716726a2d72a292ba1dfb29566c86153brianp The integer is
ad862ab5716726a2d72a292ba1dfb29566c86153brianp "png_uint_16 year" in png_time_struct.
347c9301068524042be654db3b2b055a9ec20633rpluem The strings are
347c9301068524042be654db3b2b055a9ec20633rpluem "png_charp time_buffer" in png_struct and
1266e0c1535091b37a0c6ea86183094e575cb8dagregames "near_time_buffer", which is a local character string in png.c.
29d3b95754d5730dde08bbda9dc76785894f10f8rpluem There are seven time-related functions:
dfd7e0be46ab5ef5b84339b4645d60fdc44cb4a5rpluem png_convert_to_rfc_1123() in png.c
dfd7e0be46ab5ef5b84339b4645d60fdc44cb4a5rpluem (formerly png_convert_to_rfc_1152() in error)
dfd7e0be46ab5ef5b84339b4645d60fdc44cb4a5rpluem png_convert_from_struct_tm() in pngwrite.c, called in pngwrite.c
7461431ba407b0e1eac3d6a81440a4184e652e9fniq png_convert_from_time_t() in pngwrite.c
7461431ba407b0e1eac3d6a81440a4184e652e9fniq png_get_tIME() in pngget.c
17d53ea32c4968e47733f1c2c063ae07d280efd6jerenkrantz png_handle_tIME() in pngrutil.c, called in pngread.c
17d53ea32c4968e47733f1c2c063ae07d280efd6jerenkrantz png_set_tIME() in pngset.c
17d53ea32c4968e47733f1c2c063ae07d280efd6jerenkrantz png_write_tIME() in pngwutil.c, called in pngwrite.c
b38565306421ff53e9f7499bc728d6df5cec294dpquerna All appear to handle dates properly in a Y2K environment. The
b38565306421ff53e9f7499bc728d6df5cec294dpquerna png_convert_from_time_t() function calls gmtime() to convert from system
b38565306421ff53e9f7499bc728d6df5cec294dpquerna clock time, which returns (year - 1900), which we properly convert to
b38565306421ff53e9f7499bc728d6df5cec294dpquerna the full 4-digit year. There is a possibility that applications using
3aeb30211790fef38a8297f990b7ad3b2c46ece9colm libpng are not passing 4-digit years into the png_convert_to_rfc_1123()
3aeb30211790fef38a8297f990b7ad3b2c46ece9colm function, or that they are incorrectly passing only a 2-digit year
79d1d5666b3ceb59c959b09600aa2bce32324677rpluem instead of "year - 1900" into the png_convert_from_struct_tm() function,
79d1d5666b3ceb59c959b09600aa2bce32324677rpluem but this is not under our control. The libpng documentation has always
79d1d5666b3ceb59c959b09600aa2bce32324677rpluem stated that it works with 4-digit years, and the APIs have been
a6ea86151dd968120a12b48867d45947ef2bb9darpluem documented as such.
a6ea86151dd968120a12b48867d45947ef2bb9darpluem The tIME chunk itself is also Y2K compliant. It uses a 2-byte unsigned
a6ea86151dd968120a12b48867d45947ef2bb9darpluem integer to hold the year, and can hold years as large as 65535.
a17ca1093e7dc28c1a54cfd9741f65653f5b2b19jim zlib, upon which libpng depends, is also Y2K compliant. It contains
a17ca1093e7dc28c1a54cfd9741f65653f5b2b19jim no date-related code.
fa735cac4e86858f11c0de4f7cea50fa63eab87ecolm Glenn Randers-Pehrson
dbb3b82abaa9c0ad199a0a3d6a7a505136137c61colm libpng maintainer
dbb3b82abaa9c0ad199a0a3d6a7a505136137c61colm PNG Development Group