在java.util.Date
:爲什麼java.util.Date將Year表示爲「1900年」?
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).
,當然還有:
* 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
,仍然有這種怪異的折舊筆記被棄用,月份是0
-based,但我們都知道(儘管你會認爲他們已經從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.
我沒有檢查以下問題:
Why does Java's Date.getYear() return 111 instead of 2011?
Why is the Java date API (java.util.Date, .Calendar) such a mess?
我的問題是:
- 什麼可能是最好的原創者的
java.util.Date
希望通過存儲「年份」的數據獲得收益從它減去1900?特別是如果它基本上是長期存儲的。
這樣:
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開始計算是Unix區域的一個長C標準。由於字的大小像16位,他們花了一輪,但仍然是歷史上最近更年期。當然,感謝Joda現在在java 8中的所有內容都在新的java.time類中進行了修正,從1到12個月等等。 – 2014-10-08 11:26:01
直到2000年,從1900年的計算是方便顯示2位數年。使用兩位數字的年份也對1999年前後的IT就業市場產生了非常積極的影響。 – 2014-10-08 11:34:40
java.util.Date是一個糟糕的工作。 (這就是爲什麼Java現在有這麼多不同的日期方案。)特別是,1900年傳統上是計算機日期的開始,因爲直到2000年,年份可以在打卡上表示爲2位數(並且沒有發生重要事件1900年以前)。 – 2014-10-08 11:51:28