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>.
Конечно, в Java 1.1 метод getYear()
и ему подобные были объявлены устаревшими в пользу java.util.Calendar
, у которого все еще есть это странное примечание об устаревании:
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).
И, конечно же, Month основан на 0
, но мы все это знаем (хотя можно подумать, что они убрали эту проблему из Calendar
— это не так):
* <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.
Я проверил следующие вопросы:
Почему Java Date.getYear() возвращает 111 вместо 2011?
Почему API даты Java (java.util.Date, .Calendar) такой беспорядок?
Мой вопрос:
- Что, возможно, могли получить первоначальные создатели
java.util.Date
от хранения данных «года», вычитая из него 1900? Особенно, если он в основном хранится как long.
Как таковой:
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);
....
- Почему 1900?