Java 为什么不推荐使用“new Date(int year, int month, int day)”？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/460423/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why was "new Date(int year, int month, int day)" deprecated?
提问by Scott Bennett-McLeish
My application I've recently inherited is FULL of deprecation warnings about the constructor:
我最近继承的应用程序充满了关于构造函数的弃用警告：
Date d = new Date(int year, int month, int day)
Does anyone know or can point to a reason why something as simple as this was "replaced" with something like this:
有谁知道或可以指出一个原因，为什么像这样简单的东西被“替换”为这样的东西：
Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();
Now, obviously deprecation warnings are not a problem in themselves, but can you imagine the millions of LOC that would be crying out in agony if this constructor was ever removed?
现在，显然弃用警告本身不是问题，但是你能想象如果这个构造函数被删除，数百万的 LOC 会痛苦地哭泣吗？
In my brief little play at benchmarking, the latter takes about 50% more time to execute.
在我对基准测试的简短介绍中，后者的执行时间增加了大约 50%。
采纳答案by Michael Borgwardt
Originally, Datewas intended to contain all logic concerning dates, but the API designers eventually realized that the API they had so far was woefully inadequate and could not be cleanly extended to deal correctly with issues such as timezones, locales, different calendars, daylight savings times, etc.
最初，Date旨在包含所有与日期相关的逻辑，但 API 设计者最终意识到，他们目前拥有的 API 严重不足，无法彻底扩展以正确处理诸如时区、区域设置、不同日历、夏令时等问题， 等等。
So they created Calendarto deal with all that complexity, and relegated Dateto a simple timestamp, deprecating all its functionality that dealt with formatting, parsing and individual date fields.
所以他们创建Calendar来处理所有这些复杂性，并降级Date为一个简单的时间戳，弃用其处理格式、解析和单个日期字段的所有功能。
BTW, internally these methods such as Date(int, int, int)constructor now call Calendar, so if you see a difference in speed, then you're doing something wrong when calling Calendar.
顺便说一句，在内部这些方法（例如Date(int, int, int)构造函数）现在调用Calendar，因此如果您发现速度差异，那么您在调用Calendar.
The bottomline: It's not Java's CalendarAPI that is overly complex, it's the human concept of dates, and the only problem with Calendaris that it offers not much in the way of shortcuts to the most common usages.
底线：不是 Java 的CalendarAPI 过于复杂，而是人为的日期概念，唯一的问题Calendar是它没有为最常见用法提供太多快捷方式。
回答by guerda
The answer is portability.
答案是便携性。
The class Dateis not very flexible. You can define dates, but not with any transformation into other calendar formats. So Sun decided to use an additional class hierarchy (Calendar) to make it more flexible.
这门课Date不是很灵活。您可以定义日期，但不能转换为其他日历格式。因此 Sun 决定使用额外的类层次结构 ( Calendar) 使其更加灵活。
Nonetheless, it's not very handy.
尽管如此，它并不是很方便。
回答by Einar
The Java Date APIs have long been critized, see for instance this thread.
Java 日期 API 长期以来一直受到批评，例如参见此线程。
You might want to check out Joda-Timeor Apache Commons Langfor alternative Date/Time utilities.
您可能想查看Joda-Time或Apache Commons Lang以获取替代的日期/时间实用程序。
回答by Adeel Ansari
Mostly because the original java.util.Date was bloated and not completely timezone aware and not internationalization friendly.
主要是因为原始的 java.util.Date 是臃肿的，并且不完全了解时区并且不适合国际化。
However, Date is still in use and very well, in Value Objects, or say as a data type. As far as you make it immutable explicitly, you can go with ease. I tend to think it must be immutable, for other purpose we have Calendar to manipulate. Where its lot of manipulation expected, one should consider something like, Joda-Time.
但是，Date 仍在使用中并且非常好，在值对象中，或者说作为一种数据类型。只要您明确地使其不可变，您就可以轻松进行。我倾向于认为它必须是不可变的，出于其他目的，我们有 Calendar 可以操作。在预期进行大量操作的地方，应该考虑诸如 Joda-Time 之类的东西。
[Edited]
[编辑]
Just don't instantiate the Date, in the latter code. Its of no use. You may achieve a better result for your benchmark.
只是不要在后面的代码中实例化日期。它没有用。您可能会获得更好的基准测试结果。
回答by bobince
Of course, no-one ever uses any other calendar format, but the new API increases the amount of code to write for the 99% common case, so it's a great boon for Java programmers paid by LoC.
当然，没有人使用任何其他日历格式，但新的 API 增加了为 99% 的常见情况编写的代码量，因此对于由 LoC 支付的 Java 程序员来说，这是一个巨大的福音。
回答by Tihamer Toth-Fejel
Michael Borgwardt had the best answer, technically. But why is he blaming humans for the way our solar system is laid out?
从技术上讲，迈克尔·博格沃特 (Michael Borgwardt) 给出了最佳答案。但是为什么他要责怪人类对我们太阳系的布局方式呢？
OK, we came up with the idea of seconds, and minutes, and hours.
好的，我们想出了秒、分钟和小时的想法。
But it's not our fault that that Earth's day is approximate (depending on whether we're talking about true solar day, mean solar day, or stellar day, each of which varies periodically and randomly). It isn't our fault that the time of Earth's orbit around the Sun is approximately365 days, and it's not our fault that the moon's orbit around the Earth is approximately27.3 days (depending on whether we're talking about a sidereal, synodic, tropical, anomalistic, or draconic (nodical) month).
但地球日是近似值并不是我们的错（取决于我们是在谈论真太阳日、平均太阳日还是恒星日，每个日都周期性地随机变化）。地球绕太阳公转一周的时间约为365 天不是我们的错，月球绕地球公转一周的时间约为27.3 天也不是我们的错（取决于我们是否在谈论恒星、会合、热带、异常或龙（节）月）。
Aren't you glad that Calendar didn't take all those details into account? Then our software bugs might indeed be dependent on the phase of the moon.
日历没有考虑所有这些细节，您不高兴吗？那么我们的软件错误可能确实取决于月相。
