1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/Y2K	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,145 @@
     1.4 +/* ========================================================================
     1.5 + * Copyright 1988-2006 University of Washington
     1.6 + *
     1.7 + * Licensed under the Apache License, Version 2.0 (the "License");
     1.8 + * you may not use this file except in compliance with the License.
     1.9 + * You may obtain a copy of the License at
    1.10 + *
    1.11 + *     http://www.apache.org/licenses/LICENSE-2.0
    1.12 + *
    1.13 + * 
    1.14 + * ========================================================================
    1.15 + */
    1.16 +
    1.17 +QUESTION: Is c-client Y2K compliant?
    1.18 +
    1.19 +ANSWER:
    1.20 +
    1.21 +     There are no known Y2K issues in c-client; nor have there ever
    1.22 +been any known Y2K issues in c-client from its inception.
    1.23 +
    1.24 +     Some older versions of c-client don't like the two-digit year
    1.25 +"00", although the only impact of this is that messages with that year
    1.26 +will sort before any other messages.  Nobody should be using two-digit
    1.27 +years in email messages any more (use "2000" instead of "00").
    1.28 +
    1.29 +     You may wish to read the document calendar.txt for more
    1.30 +information about the Y3.3K/Y4K, Y20K, and Y4)K issues.  Assuming that
    1.31 +c-client is still around in 2000-40,000 years, someone will have to
    1.32 +deal with these.
    1.33 +
    1.34 +     Within the plausible lifetimes of people today, there are three
    1.35 +known date-related issues in c-client which will have to be addressed
    1.36 +in the future.  If I am still alive when the first problem hits, I
    1.37 +will be nearly 82 years old, and won't be maintaining c-client any
    1.38 +more.
    1.39 +
    1.40 +
    1.41 +Y2038:
    1.42 +
    1.43 +     c-client, like most UNIX software, has Y2038 issues.  On Tuesday,
    1.44 +January 19, 2038 at 03:14:08 Coordinated Universal Time (also known as
    1.45 +UTC, UT, or historically GMT), the clock on 32-bit UNIX systems will
    1.46 +wrap around to a negative number; that is, from 0x7fffffff to
    1.47 +0x80000000.
    1.48 +
    1.49 +     c-client uses an unsigned long for its 32-bit time; however the C
    1.50 +library on most UNIX systems uses a signed long and will interpret
    1.51 +that time as being Friday, December 13, 1901 at 20:45:52 UTC.
    1.52 +
    1.53 +     Fixing this problem will require changing the C library to use
    1.54 +either unsigned longs or a wider (e.g. 64-bit) value for time.  Lots
    1.55 +of work will need to be done on 32-bit UNIX systems as 2038
    1.56 +approaches.  History suggests that most of the work will be done in
    1.57 +the autumn of 2037... ;-) It's not known if anything is necessary to
    1.58 +do to c-client other than just rebuild it with the new C library.
    1.59 +
    1.60 +     Going to 32-bit unsigned longs means that there will be a Y2106
    1.61 +bug that someone will have to fix.  Hopefully nobody will even think
    1.62 +of using 32-bit systems by then.
    1.63 +
    1.64 +
    1.65 +Y2070:
    1.66 +
    1.67 +     c-client assumes that 2-digit years with values of 70 or greater
    1.68 +are in the 20th century, and that 2-digit years with values of 69 or
    1.69 +less are in the 21st century.  Time for UNIX began on January 1, 1970
    1.70 +and email on ARPAnet happened between the first TENEX systems shortly
    1.71 +after that; consequently there is no ambiguity with email data with
    1.72 +2-digit years prior to the year 2070.  This is used only when parsing
    1.73 +a 2-digit year.  c-client never generates one.
    1.74 +
    1.75 +     Fixing this problem requires convincing people not to use 2-digit
    1.76 +years.  This is a lesson that people should have figured out 70 years
    1.77 +earlier with Y2K.  Consequently, this may be a "non-problem."
    1.78 +Otherwise, look in mail_parse_date() for the comment "two digit year"
    1.79 +and change the statement as desired.  [Note: do not change the
    1.80 +definition of BASEYEAR since the UNIX port assumes that this matches
    1.81 +when time began in the operating system.]
    1.82 +
    1.83 +
    1.84 +Y2098:
    1.85 +
    1.86 +     On January 1, 2098, the year in per-message internal dates will
    1.87 +expire, since a 7-bit field is allocated for the year.  c-client will
    1.88 +mistakenly think that the day is January 1, 1970.
    1.89 +
    1.90 +     Fortunately, it is easy to fix this problem.  Just increase the
    1.91 +width of "year" in MESSAGECACHE in mail.h.  If you make it 8 bits,
    1.92 +it'll be good until January 1, 2216; 9 bits makes it good until 2482.
    1.93 +10 bits will push it back that you'd worry about the Y2800 question
    1.94 +before having to increase it again.  If you ignore Y2800, 11 bits will
    1.95 +push it it back to having to worry about Y4K first.
    1.96 +
    1.97 +
    1.98 +Y2800:
    1.99 +
   1.100 +     At this year, you will need to decide whether to keep the Gregorian
   1.101 +calendar, which is one day slow every 20,000 years, or go to the more
   1.102 +accurate Eastern Orthodox calendar which is one day slow every 45,000
   1.103 +years.  The Gregorian and Eastern Orthodox calendars diverge at this
   1.104 +year.
   1.105 +
   1.106 +     There hasn't been any statement about how the international
   1.107 +community will deal with the situation of the Orthodox calendar being
   1.108 +one day ahead of the Gregorian calendar between 2800 and 2900.  This
   1.109 +will happen again between 3200 and 3300, and at gradually increasing
   1.110 +intervals until 48,300 when the shift becomes permanent (assuming no
   1.111 +Y20K or Y40K fixes).
   1.112 +
   1.113 +     If you wish to make the transition to the Eastern Orthodox calendar,
   1.114 +rebuild c-client with -DUSEORTHODOXCALENDAR=1.  You can then ignore Y4K
   1.115 +and Y20K!
   1.116 +    
   1.117 +
   1.118 +Y3.3K/Y4K:
   1.119 +
   1.120 +     Some time around the year 3300, the calendar has gotten one day
   1.121 +behind.  To remedy this, a little-known rule in the Gregorian calendar
   1.122 +is that years that are evenly divisible by 4000 are not leap years.
   1.123 +Unlike the other rules, this rule hasn't had effect yet, and won't for
   1.124 +another 2000 years.
   1.125 +
   1.126 +     To fix the Y4K problem, just rebuild c-client with -DY4KBUGFIX=1.
   1.127 +
   1.128 +
   1.129 +Y20K:
   1.130 +
   1.131 +     Those of you who stuck with the Gregorian calendar have a
   1.132 +problem; the calendar is now one day slow.  The Pope has not made any
   1.133 +statement about how this problem will be fixed.  Maybe they'll declare
   1.134 +that 20,004 is also not a leap year or something.
   1.135 +
   1.136 +     There is no fix for this problem in c-client.
   1.137 +
   1.138 +
   1.139 +Y40K:
   1.140 +
   1.141 +     Greeks, Serbs, Russians, and other Eastern Orthodox have spent
   1.142 +the past 38,000 years laughing at westerners' increasingly futile
   1.143 +efforts to keep the Gregorian calendar in order.  The day of reckoning
   1.144 +has come; the Orthodox calendar is now one day slow.  The Patriarch of
   1.145 +Istanbul (nee Constantinople) has not made any statement about how this
   1.146 +will be fixed.
   1.147 +
   1.148 +     There is no fix for this problem in c-client.