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