Java Date类。最好的例子之一就是如何不以任何语言在任何地方做某事。我该从哪里开始？
阅读JavaDoc可能会使人们认为开发人员实际上有了一些好主意。它接着约之间的区别UTC和GMT在长度，尽管两者之间的差别基本上是闰秒（这发生非常 罕见）。
但是，设计决定实际上是在浪费任何被认为是设计良好的API的想法。以下是一些最喜欢的错误：
- 尽管在上个千年的最后十年中进行了设计，但自1900年以来，它的年数一直是两位数。由于这个平庸的决定，在Java世界中确实有数百万种变通方法在进行1900+（或1900-）的开发。
- 月被索引为零，以迎合一个异常的情况，即月数组不包含13个元素的数组，其中第一个元素包含
null
。结果，我们有0..11（今天是109年的第11个月）。为了转换为字符串，在月份中有类似数量的++和-。 - 他们是可变的。结果，任何时候你想要返回一个日期（例如，作为实例结构），都需要返回该日期的副本，而不是日期对象本身（否则，人们可以更改你的结构）。
- 的
Calendar
，旨在“修复”这一点，实际上使同样的错误。他们仍然是可变的。 Date
代表DateTime
，但为了顺应SQL领域的需求，还有另一个子类java.sql.Date
，代表了一天（尽管没有与之关联的时区）。- 没有
TimeZone
与关联的Date
，因此范围（例如“全天”）通常表示为午夜至午夜（通常在任意时区）
最后，值得注意的是，leap秒通常会在一个小时之内用ntp更新的良好系统时钟纠正自身（请参见下面的链接）。在引入两个leap跃秒（最少每六个月，实际上每隔几年）的情况下，系统仍然可以运行的可能性非常小，尤其是考虑到必须不时重新部署新版本的代码这一事实。即使使用重新生成类或诸如WAR引擎之类的动态语言，也会污染类空间并最终耗尽permgen。
