Yes, Java is Y2K safe. That was the first date-related question people asked before 2,000 AD rolled around, so I’ll answer it up front. The difficulties of date handling in Java arise not from Y2K issues but from Y1970 issues.
When Java was devised in the early 1990s, there was already considerable awareness in the computing industry of the impending problems with some old code. In fairness to practitioners of the 1970s and 1980s, I must add that not all of us ignored the Y2K issue. I read a key early warning sounded around 1974 in Datamation or JACM, and many of my colleagues from that time forward (myself included) paid close attention to issues of date survivability, as did the developers of the Java API.
In the earliest releases of Java, there was a class called
Date
designed
for representing and operating upon dates. Its problems were that it
was Anglocentric -- like much of Java 1.0 -- and that its dates
began with the Unix time epoch: January 1, 1970. The year is an
integer whose minimum value 70 is treated as 1970, so 99 is 1999, 100
is 2000, and so on. Consequently, there is no general Y2K problem
with Java. The problem remains that those of us ancient enough to
have been born before that venerable year of 1970 in the history of
computing -- the time when Unix was invented -- found ourselves
unable to represent our birth dates, and this made us grumpy and
irritable.
The Anglocentricity and 1970-centricity could have been vanquished
with Java 1.1. A new class,
Calendar
, was devised, with hooks for
representing dates in any date scheme such as the western (Christian)
calendar, the Hebrew calendar, the Islamic calendar, the Chinese
calendar, and even Star Trek Star dates. Unfortunately, there
wasn’t enough time to implement any of these. In fact, only the
GregorianCalendar
class appears in Java 1.1, and Java 2
does little to solve the problem (though it does fix the
Date
class to allow it to represent years before
1970.) You may have to go to other sources to get additional Calendar
classes; one source is listed in Section 6.4.
The Calendar
class can represent any date, BC or
AD, in the western calendar. A separate Java int
variable, with 32 bits of storage, is allocated for each item such as
year, month, day, and so on. Years are signed, negative numbers
meaning before the calendar epoch and positive numbers after it. The
term
epoch
means the beginning of recorded
time. In the western world, our calendar epoch is the imaginary year
0, representing the putative birth year of Jesus Christ. This is such
an important event that the years before it are called Before Christ
or BC, and dates since then are called . . . well, not After Christ,
but the Latin anno domini, meaning
“in the year of our Lord.” Because that takes too long to
say and write, we use the acronym AD, thus proving that computerists
take no blame whatsoever for inventing the use of acronyms. In the
modern spirit of political correctness, these terms have been renamed
to BCE (Before Common Era) and CE (Common Era), but to most
westerners born before about 1980 they will always be BC and AD. The
GregorianCalendar
class, intended to represent
western or Christian dates, also uses BC and AD.
Where was I? Oh yes, Java. As int
s in Java are 32
bits, that allows 2^31, or 2,147,483,648, years. Let’s say
roughly two billion years. I, for one, am not going to worry about
this new Y2B menace -- even if I’m still around, I’m
sure they’ll have gone to a 64-bit integer by then.
Fortunately, in Java 2 (JDK 1.2), the Date
class
was changed to use long values, and it can now represent a
much wider range of dates. And what about this new
DateFormat
class? Well, it does provide a great
deal of flexibility in the formatting of dates. Plus, it’s
bidirectional -- it can parse dates too. We’ll see it in
action in Recipes Section 6.3 and Section 6.6.
Note also that some of these classes are in
java.text
while others are in
java.util
. Package
java.text
contains classes and interfaces for
handling text, dates, numbers, and messages in a manner independent
of natural languages, while java.util
contains the
collections framework, legacy collection classes, event model, date
and time facilities,
internationalization, and miscellaneous
utility classes. You’ll need to import both packages in most
date-related programs.
3.145.71.115