fixing RawBitmap access

[wxWidgets.git] / src / png / Y2KINFO

diff --git a/src/png/Y2KINFO b/src/png/Y2KINFO
index bf41676ffb76e0d3da6be3f291cefe7afb270315..5d1f2f7ac9c7d19e018694f787e34d94630fb540 100644 (file)
--- a/src/png/Y2KINFO
+++ b/src/png/Y2KINFO
@@ -1,29 +1,29 @@
    Y2K compliance in libpng:
    =========================
-      
-      January 13, 1999
-      
+
+      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.81 and
-      upward are Y2K compliant.  It is my belief that earlier versions were
-      also Y2K compliant.
-      
+
+      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 
+          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
@@ -31,22 +31,25 @@
           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 
+
+      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 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.
-      
+      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