Java中setyear和getyear_为什么java.util.Date将Year表示为“year-1900”?

探讨了Java中java.util.Date类的设计原理,尤其是关于年份表示方式的由来,并解释为何选择了1900作为基准年。

在java.util.Date中:

* In all methods of class Date that accept or return

* year, month, date, hours, minutes, and seconds values, the

* following representations are used:

*

*

A year y is represented by the integer

* y-1900.

当然,在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但我们都知道(尽管你认为他们已经从日历中删除了这个问题 – 他们没有):

*

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.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?

解决方法:

基本上原始的java.util.Date设计师从C中复制了很多.你看到的是结果 – 见tm struct.所以你应该问为什么那个设计用于1900年.我怀疑根本答案是“因为我们在设计tm时不太擅长API设计.”我认为,就日期和时间而言,我们仍然不擅长API设计,因为有太多不同的用例.

这只是API,而不是java.util.Date中的存储格式.同样烦人,请注意.

标签:java,date,offset,java-util-date

来源: https://codeday.me/bug/20190714/1459362.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值