1 Y2K compliance in libpng:
2 =========================
6 Since the PNG Development group is an ad-hoc body, we can't make
7 an official declaration.
9 This is your unofficial assurance that libpng from version 0.81 and
10 upward are Y2K compliant. It is my belief that earlier versions were
13 Libpng only has three year fields. One is a 2-byte unsigned integer
14 that will hold years up to 65535. The other two hold the date in text
15 format, and will hold years up to 9999.
18 "png_uint_16 year" in png_time_struct.
21 "png_charp time_buffer" in png_struct and
22 "near_time_buffer", which is a local character string in png.c.
24 There are seven time-related functions:
26 png_convert_to_rfc_1123() in png.c
27 (formerly png_convert_to_rfc_1152() in error)
28 png_convert_from_struct_tm() in pngwrite.c, called in pngwrite.c
29 png_convert_from_time_t() in pngwrite.c
30 png_get_tIME() in pngget.c
31 png_handle_tIME() in pngrutil.c, called in pngread.c
32 png_set_tIME() in pngset.c
33 png_write_tIME() in pngwutil.c, called in pngwrite.c
35 All appear to handle dates properly in a Y2K environment. The
36 png_convert_from_time_t() function calls gmtime() to convert from system
37 clock time, which returns (year - 1900), which we properly convert to
38 the full 4-digit year. There is a possibility that applications using
39 libpng are not passing 4-digit years into the png_convert_to_rfc_1123()
40 function, or incorrectly passing only a 2-digit year instead of
41 "year - 1900" into the png_convert_from_struct_tm() function, but this
42 is not under our control. The libpng documentation has always stated
43 that it works with 4-digit years, and the APIs have been documented as
46 The tIME chunk itself is also Y2K compliant. It uses a 2-byte unsigned
47 integer to hold the year, and can hold years as large as 65535.