EpicPandaForce
EpicPandaForce

Reputation: 81539

Why does java.util.Date represent Year as "year-1900"?

In java.util.Date:

 * In all methods of class <code>Date</code> that accept or return
 * year, month, date, hours, minutes, and seconds values, the
 * following representations are used:
 * <ul>
 * <li>A year <i>y</i> is represented by the integer
 *     <i>y</i><code>-1900</code>.

Of course, in Java 1.1, the getYear() method and the like were deprecated in favor of java.util.Calendar, which still has this weird deprecation note:

 int    getYear() 
    Deprecated. As of JDK version 1.1, replaced by Calendar.get(Calendar.YEAR) - 1900.

 setYear(int year) 
      Deprecated. As of JDK version 1.1, replaced by Calendar.set(Calendar.YEAR, year + 1900).

And of course, Month is 0-based but we all know that (although you'd think they had removed that problem from Calendar - they didn't):

 * <li>A month is represented by an integer from 0 to 11; 0 is January,
 *     1 is February, and so forth; thus 11 is December.

I did check the following questions:

Why does Java's Date.getYear() return 111 instead of 2011?

Why is the Java date API (java.util.Date, .Calendar) such a mess?

My question is:

As such:

private transient long fastTime;

@Deprecated
public int getYear() {
    return normalize().getYear() - 1900;
} 

@Deprecated
public void setYear(int year) {
    getCalendarDate().setNormalizedYear(year + 1900);
}

private final BaseCalendar.Date getCalendarDate() {
    if (cdate == null) {
        BaseCalendar cal = getCalendarSystem(fastTime);
    ....

Upvotes: 10

Views: 14818

Answers (3)

Basil Bourque
Basil Bourque

Reputation: 338516

tl;dr

Use java.time classes only. Never use Date, Calendar, etc.

LocalDate
.of( 2025 , 1 , 23 )  // January 23, 2025. No crazy numbering.
.getYear( 2025 )      // Returns 2025. No crazy numbering. 

Avoid legacy date-time classes

The legacy date-time classes such as Date, Calendar, SimpleDateFormat, and more are terribly flawed in many ways. You have found a few of those ways.

Fortunately, the “why” is now moot. These classes were supplanted entirely by the modern java.time classes built into Java 8 and later, as defined in JSR 310.

LocalDate

For a date-only value, without time-of-day, and without time zone or offset, use java.time.LocalDate.

The java.time classes use sane numbering. So a year number is, well, the year number. For the year 2025, use 2025. Forget about the "1900" mess with the legacy classes.

LocalDate ld = LocalDate.of( 2025 , Month.JANUARY , 23 ) ;  // Year number is the year number.

Or use month number. Again, sane numbering: 1-12 for January-December, in contrast to the legacy classes. Forget about the 0-based month mess with the legacy classes.

LocalDate ld = LocalDate.of( 2025 , 1 , 23 ) ; // 1-12 for January-December.

Interrogate for the year number.

int year = ld.getYear() ;

If you put 2025 in, you get 2025 out.

2025

Upvotes: 1

Jon Skeet
Jon Skeet

Reputation: 1500495

Basically the original java.util.Date designers copied a lot from C. What you're seeing is the result of that - see the tm struct. So you should probably ask why that was designed to use the year 1900. I suspect the fundamental answer is "because we weren't very good at API design back when tm was designed." I'd contend that we're still not very good at API design when it comes to dates and times, because there are so many different use cases.

This is just the API though, not the storage format inside java.util.Date. No less annoying, mind you.

Upvotes: 16

Bartosz Bilicki
Bartosz Bilicki

Reputation: 13235

java.util.Date is no date at all. It is (quoting http://docs.oracle.com/javase/6/docs/api/java/util/Date.html) specific instant in time, with millisecond precision.

It has no relationship with any particular date, hour, etc. You may extract day, year, etc from it- using given calendar and timezone. Diffrent calendars, timezones will give diffrent dates.

If you are ever interested in storing date (day, month, year) do not use java.util.Date

Instead

Upvotes: 3

Related Questions