[wxWidgets.git] / src / png / Y2KINFO

   Y2K compliance in libpng:
   =========================

      September 12, 2004

      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.7 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
Commit	Line	Data
75b6e0a0 GD	1	Y2K compliance in libpng:
75b6e0a0 GD	2	=========================
4946a942	3
706b8807	4	September 12, 2004
4946a942	5
75b6e0a0 GD	6	Since the PNG Development group is an ad-hoc body, we can't make
75b6e0a0 GD	7	an official declaration.
4946a942 GD	8
4946a942 GD	9	This is your unofficial assurance that libpng from version 0.71 and
706b8807	10	upward through 1.2.7 are Y2K compliant. It is my belief that earlier
4946a942 GD	11	versions were also Y2K compliant.
4946a942 GD	12
75b6e0a0 GD	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.
4946a942	16
75b6e0a0 GD	17	The integer is
75b6e0a0 GD	18	"png_uint_16 year" in png_time_struct.
4946a942	19
75b6e0a0 GD	20	The strings are
	21	"png_charp time_buffer" in png_struct and
	22	"near_time_buffer", which is a local character string in png.c.
4946a942	23
75b6e0a0 GD	24	There are seven time-related functions:
75b6e0a0 GD	25
4946a942	26	png_convert_to_rfc_1123() in png.c
75b6e0a0 GD	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
4946a942 GD	34
4946a942 GD	35	All appear to handle dates properly in a Y2K environment. The
75b6e0a0 GD	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()
4946a942 GD	40	function, or that they are incorrectly passing only a 2-digit year
	41	instead of "year - 1900" into the png_convert_from_struct_tm() function,
	42	but this is not under our control. The libpng documentation has always
	43	stated that it works with 4-digit years, and the APIs have been
	44	documented as such.
	45
75b6e0a0 GD	46	The tIME chunk itself is also Y2K compliant. It uses a 2-byte unsigned
75b6e0a0 GD	47	integer to hold the year, and can hold years as large as 65535.
4946a942 GD	48
	49	zlib, upon which libpng depends, is also Y2K compliant. It contains
	50	no date-related code.
	51
	52
75b6e0a0 GD	53	Glenn Randers-Pehrson
	54	libpng maintainer
	55	PNG Development Group