java.util.date和java.sql.date,java util date 和sql date

　　日期和时间的工作基本上相当复杂，而且充满了拐弯抹角。这是可以管理的，但是你需要一些时间来理解它。java.util.Date类在很多方面都很糟糕(细节如下)。总的来说，开发者对它的理解很差。它被图书馆作者严重滥用，进一步加剧了混乱。关于java.util.Date，需要了解的最重要的事情是：

　　如果可能的话，应该避免。用java.time.*如果可能的话，也可以用ThreeTen Backport(基本上是java.time的老版本)或者Joda time(如果你还没有用过java 8的话)。如果您被迫使用它，请避免使用不推荐使用的成员。在过去的20年里，大部分都被放弃了，这是有原因的。如果你真的觉得必须使用不推荐的成员，请确保你真的了解他们。Date实例表示某个时刻，而不是日期。重要的是，这意味着：它没有时区。它没有格式。它没有日历系统。现在，关于细节…

Java.Util.Date有什么问题？

Java . util . Date(Date from now)是一个不好的类型，这也解释了为什么Java 1.1中那么多的Date都被弃用(可惜现在还在用)。

　　设计缺陷包括：

　　它的名字具有误导性：它不代表日期，它代表时间中的一个瞬间。因此，它应该被称为Instant，就像它的java.time等价物一样。这是一个非最终的结果：它鼓励了对继承(如java)的不当使用。Java.sql.Date(表示日期，也容易混淆，因为有相同的简称)。它是可变的：日期/时间类型是由不可变类型有效建模的自然值。日期是可变的(例如，通过setTime方法)，这意味着勤奋的开发人员最终将在任何地方创建防御性副本。它在很多地方都隐式地使用了系统的本地时区，包括toString()，这让很多开发者很困惑。它的月份号是从0开始的，是从c语言复制过来的，这导致了很多很多的错误。它的年号是以1900年为基准，抄袭c的，当然Java出来的时候我们就已经有了这样的想法，对可读性不好？其方法的名称不明确：getDate()返回一个月中的某一天，getDay()返回一周中的某一天。给这些更具描述性的名字有多难？是否支持闰秒不清楚：“一秒用0到61之间的整数表示；值60和61只出现在闰秒中，甚至只出现在实际正确跟踪闰秒的Java实现中。”我强烈怀疑大部分开发者(包括我自己)都做了很多假设，认为getSeconds()的取值范围其实在0-59之间(含)。没有明显的理由，它是宽大的：“在所有情况下，为这些目的给出的方法的参数不需要在规定的范围内；例如，日期可以指定为1月32日，也可以解释为2月1日。这个有用吗？我可以发现更多的问题，但是他们会越来越挑剔。这是一个非常丰富的列表。好的一面是：

　　它显式表示一个值：一个时刻，没有相关的日历系统、时区或文本格式，精确到毫秒。可惜开发者对这个“好的方面”的理解很差。让我们打开它.

什么是“瞬间”

注意：在本文的其余部分，我忽略了相对论和闰秒。它们对某些人来说很重要，但对大多数读者来说，只会带来更多的困惑。

　　当我谈到“时刻”时，我指的是可以用来识别何时发生了什么的概念。这可能在未来发生，但从过去考虑最容易。)它独立于时区和日历系统，因此使用“本地”时间表示的多个用户可以用不同的方式谈论它。

　　让我们用一个非常具体的例子来说明在一个不使用我们熟悉的时区的地方发生了什么：尼尔阿姆斯特朗在月球上行走。在月球上行走开始于特定时刻3354如果来自世界各地的多个人同时观看，他们会(几乎)同时说“我现在就能看到它正在发生”。

　　如果你从休斯顿的任务控制中心观看，你可能会认为此刻是“1969年7月20日，9:56:20 CDT”。如果你在伦敦看，你可能会想到那部电影

　　刻是1969年7月21日，英国夏令时凌晨3:26:20。如果你在利雅得观看，你可能会认为那一刻是1389年7月7日上午5:56:20（+03）（使用《古拉经》日历）。尽管不同的观察者会在他们的时钟上看到不同的时间，甚至不同的年份，但他们仍然会考虑同一时刻。他们只是在应用不同的时区和日历系统，将即时转换为更人性化的概念。

　　那么，计算机如何表示实例呢？它们通常在一个特定的瞬间之前或之后存储一定量的时间，而这个瞬间实际上是一个原点。许多系统使用Unix纪元，这是格里高历中以UTC表示的1970年1月1日开始的午夜。这并不意味着纪元本质上是在UTC中的——Unix纪元同样可以定义为1969年12月31日纽约下午7点的那一刻。

　　Date类使用自Unix纪元以来的毫秒数——这是getTime（）返回的值，由Date（long）构造函数或setTime（）方法设置。由于月球行走发生在Unix纪元之前，因此该值为负值：实际上是-14159020000。

　　为了演示日期如何与系统时区交互，让我们展示前面提到的三个时区–休斯顿（美国/芝加哥）、伦敦（欧洲/伦敦）和利雅得（亚洲/利雅得）。当我们从历元毫秒值构建日期时，系统时区是什么并不重要，这根本不取决于本地时区。但如果我们使用Date.toString()，它转换为当前默认时区以显示结果。更改默认时区根本不会更改日期值。对象的内部状态完全相同。它仍然表示相同的瞬间，但toString（）、getMonth（）和getDate（）等方法将受到影响。

　　下面的示例代码显示：

import java.util.Date;import java.util.TimeZone;public class Test { public static void main(String[] args) { // The default time zone makes no difference when constructing // a Date from a milliseconds-since-Unix-epoch value Date date = new Date(-14159020000L); // Display the instant in three different time zones TimeZone.setDefault(TimeZone.getTimeZone("America/Chicago")); System.out.println(date); TimeZone.setDefault(TimeZone.getTimeZone("Europe/London")); System.out.println(date); TimeZone.setDefault(TimeZone.getTimeZone("Asia/Riyadh")); System.out.println(date); // Prove that the instant hasnt changed... System.out.println(date.getTime()); }}

输出如下：

Sun Jul 20 21:56:20 CDT 1969Mon Jul 21 03:56:20 GMT 1969Mon Jul 21 05:56:20 AST 1969-14159020000
　　

这里的输出中的GMT和AST缩写非常不幸——java.util.TimeZone并非在所有情况下都具有1970年之前值的正确名称。不过时机已经成熟。

常见问题

如何将Date日期转换为其他时区？

你没有——因为约会没有时区。这是一个瞬间。不要被toString（）的输出所愚弄。这会显示默认时区中的瞬间。这不是值的一部分。

　　如果代码以日期作为输入，则已经发生了从本地时区到即时的任何转换。（希望操作正确……）

　　如果您开始编写一个带有这样签名的方法，那么您并没有帮助自己：

// A method like this is always wrongDate convertTimeZone(Date input, TimeZone fromZone, TimeZone toZone)

如何将Date日期转换为其他格式？

你没有——因为日期没有格式。不要被toString（）的输出所愚弄。始终使用相同的格式，如文档所述。要以特定方式格式化日期，请使用合适的日期格式（可能是SimpleDataFormat）——记住将时区设置为适合您使用的适当区域。

　　到此这篇关于深入了解Java.Util.Date详情的文章就介绍到这了,更多相关Java.Util.Date 内容请搜索盛行IT以前的文章或继续浏览下面的相关文章希望大家以后多多支持盛行IT！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。