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