DateTime and TimeZones in Java
In the versions before Java 8, we had Date and Calendar APIs to handle date and time. To overcome the shortcomings of the older java util Date and java util Calendar, Java 8 introduced new APIs for Date and Time. Some of the issues of the existing older java Date and Calender are mentioned below.
- Thread safety: The older Date and Calendar classes are not thread-safe. Therefore, developers have to handle the concurrency issues. But the new Date and Time APIs introduced in Java 8 are immutable and thread-safe.
- API design and ease of understanding: Older Date and Calendar APIs are poorly designed. The new Date/Time API is ISO-centric and follows consistent models for the date, time, duration, and periods.
- ZonedDate and Time: In the older version, we had to write additional logic to handle time in different time zones. But in the new version, time zone differences can be handled by the Local and ZonedDate/Time APIs.
LocalDate, LocalTime and LocalDateTime
We use these classes when time zones are not needed to be mention in our developing context. As the name indicates it represents the date and time from the observer’s context.
LocalDate
LocalDate represents in ISO format without time (YYYY-MM-dd).
Apart from that, we can pass arguments and create LocalDate instances as below.
There are several methods available for the manipulation of instances of the LocalDate class. I have mentioned two of the most used methods. You can check the Java documentation to get more information about them.
LocalTime
LocalTime represents the Time without a date. We can also use the parse and of methods or use the system clock (now) to generate LocalTime. You can see some of the commonly used methods with LocalTime below;
LocalDateTime
LocalDateTime is used to represent a combination of date and time. The most commonly used class developers go for when they need a combination of date and time. Can use the parse and of methods or use the system clock (now) with LocalDateTime to generate an instance of it.
ZonedDateTime API
If we need to deal with different time zones requirement, Java 8 provides a class called ZonedDateTime. The ZoneId is an identifier used to represent different zones. There are about 40 different time zones, and ZoneId is used to represent them.
As mentioned above, firstly, we can create a ZoneId by passing a valid time zone into its constructor. After that, we can use that ZoneId with the previously created LocalDateTime for the creation of ZonedDateTime for tracing time zone details accurately.
Apart from that, we can use LocaDateTime with OffsetDateTime to work with timezones. OffsetDateTime class tracks the offset from UTC/Greenwich, and its date and time fields are stored to a precision of nanoseconds. First, create an instance of LocalDateTime by passing arguments to the “of” method as mention above. Then create a ZoneOffset by specifying the offset amount from the UTC/Greenwich. After that, you can use that LocalDateTime with ZoneOffset for the creation of the OffsetDateTime instance. Now OffsetDateTime represent the date-time with an offset as 2015–02–20 06:30 +02:00.
Daylight Savings Time in Java
Daylight Saving Time (DST) is a practice of moving clocks forward during summer months and backward in the months of winter to leverage an additional hour of natural light (saving heating power, illumination power, enhancing the mood). We need to take this scenario into account when working with dates and times. As several countries adopt this technique.
We will see how the new Java Date/Time API handles DST according to different locations.
As mentioned above, firstly, we will create an instance of LocalDateTime, and the initial output is 2018-03-25T01:55. It’s completely unaware of Zones and Offsets; that is why we need to convert it into a fully DST ZonedDateTime. After converting to ZonedDateTime, it will give an output like 2018-03-25T01:55+01:00[Europe/Rome]. You can see the ZonedDateTime included two trailing pieces of information like +01:00 is the ZoneOffset and [Europe/Rome] is the ZoneId.
After that, as shown above, let’s trigger the DST by the addition of 15 minutes to the ZonedDateTime since 2018-03-25 01:55 am, only five minutes away from the DST shift in Italy/Rome. After the addition of those minutes, if we console log the ZonedDateTime, it will be 2018-03-25T03:05+02:00 [Europe/Rome]. Therefore you can see Java 8 has correctly incorporated the DST time changes into its ZoneDateTime API, and developers don’t need to worry about it. In the older Java Date and Calendar APIs, we have to implement additional logic to incorporate the DST time changes.
Joda-Time Library
Joda-Time library is another alternative for Java 8 Date and Time library. This library provides similar capabilities to the Java 8 Date/Time project. The artifact can be found in Maven Central by including the below pom dependency in our project.
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>2.9.4</version>
</dependency>
To represent an exact point on the timeline, we can use the Instant from the Joda package. It represents the time as the number of milliseconds from the Java epoch of 1970-01-01T00:00:00Z. In Joda, DateTimeZone can be used to represent a time zone by specifying the zone id. Using this zone information nowUtc time will be converted to a DateTime object as mentioned below.
References
For further more clarification check these resources;
