它只是Java日期/时间API的一团糟。列出问题所在将花费很长时间(而且我确定我不知道其中一半是问题)。诚然,处理日期和时间是很棘手的,但是无论如何都是这样。
帮个忙,改用Joda Time或JSR-310。
编辑:至于原因-如其他答案所述,这很可能是由于旧的C API引起的,或者只是从0开始一切的一般感觉…当然,除了日子从1开始。我怀疑最初的实施团队之外的人是否真的可以说出原因-但是,我再次敦促读者不要太担心为什么会做出错误的决定,而要全神贯注地java.util.Calendar寻找更好的东西。
一个点,这是赞成使用基于0的索引的是,它使事情变得像“名字的阵列”更容易:
// I "know" there are 12 monthsString[] monthNames = new String[12]; // and populate...String name = monthNames[calendar.get(Calendar.MONTH)];
当然,一旦你获得具有13个月的日历,此 *** 作就会失败…但是至少指定的大小是你期望的月数。
这不是一个很好的理由,但这是一个理由…
编辑:作为一种评论,它要求我对Date / Calendar错误的一些想法:
- 令人惊讶的基数(Date中的1900作为Date中的年基,已弃用的构造函数必不可少;两者均为月基)
- 可变性-使用不变类型使得很多简单的什么是真正有效的工作值
- 类型集不足:拥有
Date
和Calendar
作为其他事物很好,但是缺少“本地”值与“分区”值的分隔,日期/时间与日期对时间也是如此 - 一个使用魔术常数导致丑陋代码的API,而不是使用明确命名的方法
- 很难推理的API-有关何时重新计算事物的所有事务等
- 使用无参数的构造函数默认为“ now”,这导致难以测试的代码
- 在
Date.toString()
它总是使用系统本地时区(即现在来迷惑许多堆栈溢出用户之前)执行
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)