在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