我有一个java.util.Date
对象,或一个java.util.Calendar
对象。如何在java.time框架中将其转换为正确的类型?
我听说我们现在应该使用java.time类型来做大部分业务逻辑。当使用尚未为java.time更新的旧代码时,我需要能够来回转换。什么类型映射到java.util.Date
或java.util.Calendar
?
是的,您绝对应该尽可能使用java.time框架。
老式的日期时间类(包括java.util.Date
,java.util.Calendar
和)java.text.SimpleTextFormat
已被证明设计不良,混乱且麻烦。尽可能避免它们。但是,当您必须与这些旧类型进行互操作时,可以在新旧之间进行转换。
请继续阅读,以获取基本的介绍(有些简化),以使您适应在新旧日期时间类之间来回移动。
该java.time框架由定义JSR 310,由大获成功的启发乔达时库,并通过扩展ThreeTen-EXTRA项目。的功能的大部分被后移植到Java 6和7在ThreeTen-反向移植项目,在为Android进一步适配ThreeTenABP项目。
哪些java.time类型匹配java.util.Date
?好吧,一个java.util.Date
对象基本上代表了UTC时间轴上的一个时刻,它是日期和时间的组合。我们可以将其转换为java.time中的几种类型中的任何一种。每个都在下面讨论。请注意,一些新方法已添加到旧的日期时间类中,以促进转换。
Instant
The building block in java.time is an Instant
, a moment on the timeline in UTC with a resolution of nanoseconds.
Generally you should do much of your business logic in UTC. In such work, Instant
will be used frequently. Pass around Instant
objects, applying a time zone only for presentation to a user. When you do need to apply an offset or time zone, use the types covered further below.
java.util.Date
to Instant
Given that both Instant
and java.util.Date
are a moment on the timeline in UTC, we can easily move from a java.util.Date
to an Instant
. The old class has gained a new method, java.util.Date::toInstant
.
Instant instant = myUtilDate.toInstant();
You can go the other direction, from an Instant
to a java.util.Date
. But you may lose information about the fractional second. An Instant
tracks nanoseconds, for up to nine digits after the decimal place such as 2016-01-23T12:34:56.123456789Z
. Both java.util.Date & .Calendar are limited to milliseconds, for up to three digits after the decimal place such as 2016-01-23T12:34:56.123Z
. In this example going from Instant
to Date
means truncation of the 456789
.
java.util.Date myUtilDate = java.util.Date.from(instant);
java.util.Calendar
to Instant
What about a java.util.Calendar
instead of a java.util.Date
? Internal to the Calendar
object the date-time is tracked as a count of milliseconds from the epoch reference date-time of the first moment of 1970 in UTC (1970-01-01T00:00:00.0Z
). So this value can be converted easily to an Instant
.
Instant instant = myUtilCalendar.toInstant() ;
java.util.GregorianCalendar
to ZonedDateTime
Even better, if your java.util.Calendar
object is actually a java.util.GregorianCalendar
you can easily go directly to a ZonedDateTime
. This approach has the benefit of retaining the embedded time zone information.
Downcast from the interface of Calendar
to the concrete class of GregorianCalendar
. Then call the toZonedDateTime
and from
methods to go back and forth.
if (myUtilCalendar instanceof GregorianCalendar) {
GregorianCalendar gregCal = (GregorianCalendar) myUtilCalendar; // Downcasting from the interface to the concrete class.
ZonedDateTime zdt = gregCal.toZonedDateTime(); // Create `ZonedDateTime` with same time zone info found in the `GregorianCalendar`
}
Going the other direction…
java.util.Calendar myUtilCalendar = java.util.GregorianCalendar.from(zdt); // Produces an instant of `GregorianCalendar` which implements `Calendar` interface.
As discussed above, beware that you may be losing information about the fraction of a second. The nanoseconds in the java.time type (ZonedDateTime
) gets truncated to milliseconds in the .Calendar
/.GregorianCalendar
.
OffsetDateTime
From an Instant
we can apply an offset-from-UTC to move into a wall-clock time for some locality. An offset is a number of hours, and possibly minutes and seconds, ahead of UTC (eastward) or behind UTC (westward). The ZoneOffset
class represents this idea. The result is an OffsetDateTime
object.
ZoneOffset offset = ZoneOffset.of("-04:00");
OffsetDateTime odt = OffsetDateTime.ofInstant(instant, zoneOffset);
You can go the other direction, from an OffsetDateTime
to a java.util.Date
. Extract an Instant
and then proceed as we saw in code above. As discussed above, any nanoseconds get truncated to milliseconds (data loss).
java.util.Date myUtilDate = java.util.Date.from(odt.toInstant());
ZonedDateTime
Better yet, apply a full time zone. A time zone is an offset plus rules for handling anomalies such as Daylight Saving Time (DST).
Applying a ZoneId
gets you a ZonedDateTime
object. Use a proper time zone name (continent/region). Never use the 3-4 letter abbreviations commonly seen such as EST
or IST
as they are neither standardized nor unique.
ZoneId zoneId = ZoneId.of("America/Montreal");
ZonedDateTime zdt = ZonedDateTime.ofInstant(instant, zoneId);
You can go the other direction, from an ZonedDateTime
to a java.util.Date
. Extract an Instant
and then proceed as we saw in code above. As discussed above, any nanoseconds get truncated to milliseconds (data loss).
java.util.Date myUtilDate = java.util.Date.from( zdt.toInstant() );
And we saw further above that a ZonedDateTime
may be converted to a GregorianCalendar
.
LocalDate
Sometimes you may want a date-only value, without time-of-day and without time zone. For that, use a java.time.LocalDate
object.
See this Question for more discussion, Convert java.util.Date to java.time.LocalDate, especially this Answer written by the main man behind the invention of both Joda-Time and java.time.
The key is to go through a ZonedDateTime
(as generated in code above). We need a time zone to determine a date. The date varies around the world, with a new day dawning earlier in the east. For example, after midnight in Paris is a new day while still “yesterday” in Montréal. So while a LocalDate
does not contain a time zone, a time zone is required to determine a LocalDate
.
LocalDate localDate = zdt.toLocalDate();
Converting in the other direction from LocalDate
to a date-time means inventing a time-of-day. You can choose any time-of-day that makes sense in your business scenario. For most people, the first moment of the day makes sense. You may be tempted to hard code that first moment as the time 00:00:00.0
. In some time zones, that time may not be valid as the first moment because of Daylight Saving Time (DST) or other anomalies. So let java.time determine the correct time with a call to atStartOfDay
.
ZonedDateTime zdt = localDate.atStartOfDay(zoneId);
LocalTime
On rare occasion you may want only a time-of-day without a date and without a time zone. This concept is represented by the LocalTime
class. As discussed above with LocalDate
, we need a time zone to determine a LocalTime
even though the LocalTime
object does not contain (does not ‘remember’) that time zone. So, again, we go through a ZonedDateTime
object obtained from an Instant
as seen above.
LocalTime localTime = zdt.toLocalTime();
LocalDateTime
As with the other two Local…
types, a LocalDateTime
has no time zone nor offset assigned. As such you may rarely use this. It gives you a rough idea of a date-time but is not a point on the timeline. Use this if you mean some general date and some time that might be applied to a time zone.
For example, “Christmas starts this year” would be 2016-12-25T00:00:00.0
. Note the lack of any offset or time zone in that textual representation of a LocalDateTime
. Christmas starts sooner in Delhi India than it does in Paris France, and later still in Montréal Québec Canada. Applying each of those areas’ time zone would yield a different moment on the timeline.
LocalDateTime ldt = zdt.toLocalDateTime();
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date
, Calendar
, & SimpleDateFormat
.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.*
classes.
Where to obtain the java.time classes?
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句