X-Git-Url: https://git.pterodactylus.net/?a=blobdiff_plain;f=gtkmm-osx%2Ftrunk%2Flibpng-1.2.5%2FY2KINFO;fp=gtkmm-osx%2Ftrunk%2Flibpng-1.2.5%2FY2KINFO;h=0000000000000000000000000000000000000000;hb=a095981e18cc37a8ecc7cd237cc22b9c10329264;hp=f57e962b0f8c7b048678938a1e212756e8eea8a4;hpb=9459638ad6797b8139f1e9f0715c96076dbf0890;p=synfig.git diff --git a/gtkmm-osx/trunk/libpng-1.2.5/Y2KINFO b/gtkmm-osx/trunk/libpng-1.2.5/Y2KINFO deleted file mode 100644 index f57e962..0000000 --- a/gtkmm-osx/trunk/libpng-1.2.5/Y2KINFO +++ /dev/null @@ -1,55 +0,0 @@ - Y2K compliance in libpng: - ========================= - - October 3, 2002 - - Since the PNG Development group is an ad-hoc body, we can't make - an official declaration. - - This is your unofficial assurance that libpng from version 0.71 and - upward through 1.2.5 are Y2K compliant. It is my belief that earlier - versions were also Y2K compliant. - - Libpng only has three year fields. One is a 2-byte unsigned integer - that will hold years up to 65535. The other two hold the date in text - format, 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.c - png_convert_from_time_t() in pngwrite.c - png_get_tIME() in pngget.c - png_handle_tIME() in pngrutil.c, called in pngread.c - png_set_tIME() in pngset.c - png_write_tIME() in pngwutil.c, called in pngwrite.c - - All appear to handle dates properly in a Y2K environment. The - png_convert_from_time_t() function calls gmtime() to convert from system - clock time, which returns (year - 1900), which we properly convert to - the full 4-digit year. There is a possibility that applications using - libpng are not passing 4-digit years into the png_convert_to_rfc_1123() - function, or that they are incorrectly passing only a 2-digit year - instead of "year - 1900" into the png_convert_from_struct_tm() function, - but this is not under our control. The libpng documentation has always - stated that it works with 4-digit years, and the APIs have been - 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 - no date-related code. - - - Glenn Randers-Pehrson - libpng maintainer - PNG Development Group