xref: /plan9/sys/src/cmd/gs/libpng/Y2KINFO (revision 593dc095aefb2a85c828727bbfa9da139a49bdf4)
1*593dc095SDavid du Colombier   Y2K compliance in libpng:
2*593dc095SDavid du Colombier   =========================
3*593dc095SDavid du Colombier
4*593dc095SDavid du Colombier      December 3, 2004
5*593dc095SDavid du Colombier
6*593dc095SDavid du Colombier      Since the PNG Development group is an ad-hoc body, we can't make
7*593dc095SDavid du Colombier      an official declaration.
8*593dc095SDavid du Colombier
9*593dc095SDavid du Colombier      This is your unofficial assurance that libpng from version 0.71 and
10*593dc095SDavid du Colombier      upward through 1.2.8 are Y2K compliant.  It is my belief that earlier
11*593dc095SDavid du Colombier      versions were also Y2K compliant.
12*593dc095SDavid du Colombier
13*593dc095SDavid du Colombier      Libpng only has three year fields.  One is a 2-byte unsigned integer
14*593dc095SDavid du Colombier      that will hold years up to 65535.  The other two hold the date in text
15*593dc095SDavid du Colombier      format, and will hold years up to 9999.
16*593dc095SDavid du Colombier
17*593dc095SDavid du Colombier      The integer is
18*593dc095SDavid du Colombier          "png_uint_16 year" in png_time_struct.
19*593dc095SDavid du Colombier
20*593dc095SDavid du Colombier      The strings are
21*593dc095SDavid du Colombier          "png_charp time_buffer" in png_struct and
22*593dc095SDavid du Colombier          "near_time_buffer", which is a local character string in png.c.
23*593dc095SDavid du Colombier
24*593dc095SDavid du Colombier      There are seven time-related functions:
25*593dc095SDavid du Colombier
26*593dc095SDavid du Colombier          png_convert_to_rfc_1123() in png.c
27*593dc095SDavid du Colombier            (formerly png_convert_to_rfc_1152() in error)
28*593dc095SDavid du Colombier          png_convert_from_struct_tm() in pngwrite.c, called in pngwrite.c
29*593dc095SDavid du Colombier          png_convert_from_time_t() in pngwrite.c
30*593dc095SDavid du Colombier          png_get_tIME() in pngget.c
31*593dc095SDavid du Colombier          png_handle_tIME() in pngrutil.c, called in pngread.c
32*593dc095SDavid du Colombier          png_set_tIME() in pngset.c
33*593dc095SDavid du Colombier          png_write_tIME() in pngwutil.c, called in pngwrite.c
34*593dc095SDavid du Colombier
35*593dc095SDavid du Colombier      All appear to handle dates properly in a Y2K environment.  The
36*593dc095SDavid du Colombier      png_convert_from_time_t() function calls gmtime() to convert from system
37*593dc095SDavid du Colombier      clock time, which returns (year - 1900), which we properly convert to
38*593dc095SDavid du Colombier      the full 4-digit year.  There is a possibility that applications using
39*593dc095SDavid du Colombier      libpng are not passing 4-digit years into the png_convert_to_rfc_1123()
40*593dc095SDavid du Colombier      function, or that they are incorrectly passing only a 2-digit year
41*593dc095SDavid du Colombier      instead of "year - 1900" into the png_convert_from_struct_tm() function,
42*593dc095SDavid du Colombier      but this is not under our control.  The libpng documentation has always
43*593dc095SDavid du Colombier      stated that it works with 4-digit years, and the APIs have been
44*593dc095SDavid du Colombier      documented as such.
45*593dc095SDavid du Colombier
46*593dc095SDavid du Colombier      The tIME chunk itself is also Y2K compliant.  It uses a 2-byte unsigned
47*593dc095SDavid du Colombier      integer to hold the year, and can hold years as large as 65535.
48*593dc095SDavid du Colombier
49*593dc095SDavid du Colombier      zlib, upon which libpng depends, is also Y2K compliant.  It contains
50*593dc095SDavid du Colombier      no date-related code.
51*593dc095SDavid du Colombier
52*593dc095SDavid du Colombier
53*593dc095SDavid du Colombier         Glenn Randers-Pehrson
54*593dc095SDavid du Colombier         libpng maintainer
55*593dc095SDavid du Colombier         PNG Development Group
56