imapext-2007
view docs/Y2K @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
1 /* ========================================================================
2 * Copyright 1988-2006 University of Washington
3 *
4 * Licensed under the Apache License, Version 2.0 (the "License");
5 * you may not use this file except in compliance with the License.
6 * You may obtain a copy of the License at
7 *
8 * http://www.apache.org/licenses/LICENSE-2.0
9 *
10 *
11 * ========================================================================
12 */
14 QUESTION: Is c-client Y2K compliant?
16 ANSWER:
18 There are no known Y2K issues in c-client; nor have there ever
19 been any known Y2K issues in c-client from its inception.
21 Some older versions of c-client don't like the two-digit year
22 "00", although the only impact of this is that messages with that year
23 will sort before any other messages. Nobody should be using two-digit
24 years in email messages any more (use "2000" instead of "00").
26 You may wish to read the document calendar.txt for more
27 information about the Y3.3K/Y4K, Y20K, and Y4)K issues. Assuming that
28 c-client is still around in 2000-40,000 years, someone will have to
29 deal with these.
31 Within the plausible lifetimes of people today, there are three
32 known date-related issues in c-client which will have to be addressed
33 in the future. If I am still alive when the first problem hits, I
34 will be nearly 82 years old, and won't be maintaining c-client any
35 more.
38 Y2038:
40 c-client, like most UNIX software, has Y2038 issues. On Tuesday,
41 January 19, 2038 at 03:14:08 Coordinated Universal Time (also known as
42 UTC, UT, or historically GMT), the clock on 32-bit UNIX systems will
43 wrap around to a negative number; that is, from 0x7fffffff to
44 0x80000000.
46 c-client uses an unsigned long for its 32-bit time; however the C
47 library on most UNIX systems uses a signed long and will interpret
48 that time as being Friday, December 13, 1901 at 20:45:52 UTC.
50 Fixing this problem will require changing the C library to use
51 either unsigned longs or a wider (e.g. 64-bit) value for time. Lots
52 of work will need to be done on 32-bit UNIX systems as 2038
53 approaches. History suggests that most of the work will be done in
54 the autumn of 2037... ;-) It's not known if anything is necessary to
55 do to c-client other than just rebuild it with the new C library.
57 Going to 32-bit unsigned longs means that there will be a Y2106
58 bug that someone will have to fix. Hopefully nobody will even think
59 of using 32-bit systems by then.
62 Y2070:
64 c-client assumes that 2-digit years with values of 70 or greater
65 are in the 20th century, and that 2-digit years with values of 69 or
66 less are in the 21st century. Time for UNIX began on January 1, 1970
67 and email on ARPAnet happened between the first TENEX systems shortly
68 after that; consequently there is no ambiguity with email data with
69 2-digit years prior to the year 2070. This is used only when parsing
70 a 2-digit year. c-client never generates one.
72 Fixing this problem requires convincing people not to use 2-digit
73 years. This is a lesson that people should have figured out 70 years
74 earlier with Y2K. Consequently, this may be a "non-problem."
75 Otherwise, look in mail_parse_date() for the comment "two digit year"
76 and change the statement as desired. [Note: do not change the
77 definition of BASEYEAR since the UNIX port assumes that this matches
78 when time began in the operating system.]
81 Y2098:
83 On January 1, 2098, the year in per-message internal dates will
84 expire, since a 7-bit field is allocated for the year. c-client will
85 mistakenly think that the day is January 1, 1970.
87 Fortunately, it is easy to fix this problem. Just increase the
88 width of "year" in MESSAGECACHE in mail.h. If you make it 8 bits,
89 it'll be good until January 1, 2216; 9 bits makes it good until 2482.
90 10 bits will push it back that you'd worry about the Y2800 question
91 before having to increase it again. If you ignore Y2800, 11 bits will
92 push it it back to having to worry about Y4K first.
95 Y2800:
97 At this year, you will need to decide whether to keep the Gregorian
98 calendar, which is one day slow every 20,000 years, or go to the more
99 accurate Eastern Orthodox calendar which is one day slow every 45,000
100 years. The Gregorian and Eastern Orthodox calendars diverge at this
101 year.
103 There hasn't been any statement about how the international
104 community will deal with the situation of the Orthodox calendar being
105 one day ahead of the Gregorian calendar between 2800 and 2900. This
106 will happen again between 3200 and 3300, and at gradually increasing
107 intervals until 48,300 when the shift becomes permanent (assuming no
108 Y20K or Y40K fixes).
110 If you wish to make the transition to the Eastern Orthodox calendar,
111 rebuild c-client with -DUSEORTHODOXCALENDAR=1. You can then ignore Y4K
112 and Y20K!
115 Y3.3K/Y4K:
117 Some time around the year 3300, the calendar has gotten one day
118 behind. To remedy this, a little-known rule in the Gregorian calendar
119 is that years that are evenly divisible by 4000 are not leap years.
120 Unlike the other rules, this rule hasn't had effect yet, and won't for
121 another 2000 years.
123 To fix the Y4K problem, just rebuild c-client with -DY4KBUGFIX=1.
126 Y20K:
128 Those of you who stuck with the Gregorian calendar have a
129 problem; the calendar is now one day slow. The Pope has not made any
130 statement about how this problem will be fixed. Maybe they'll declare
131 that 20,004 is also not a leap year or something.
133 There is no fix for this problem in c-client.
136 Y40K:
138 Greeks, Serbs, Russians, and other Eastern Orthodox have spent
139 the past 38,000 years laughing at westerners' increasingly futile
140 efforts to keep the Gregorian calendar in order. The day of reckoning
141 has come; the Orthodox calendar is now one day slow. The Patriarch of
142 Istanbul (nee Constantinople) has not made any statement about how this
143 will be fixed.
145 There is no fix for this problem in c-client.