Java Reference
In-Depth Information
Chapter 12
Dates and Times
In this chapter, you will learn
•
What the new Date-Time API is
•
About the design principles behind the Date-Time API
•
About the evolution of timekeeping, time zones, and Daylight Saving Time
•
About the ISO-8601 standard for date, time, and date-time keeping
•
How to represent date, time, and date-time using the Date-Time API classes and how to query,
adjust, format, and parse them
•
How to use the legacy Date-Time API
•
How to interoperate between the legacy and new Date-Time APIs
The Date-Time API
Java 8 introduced a new Date-Time API to work with date and time. In this chapter, I will refer to the date- and
time-related classes available before Java 8 as the legacy Date-Time API. The legacy Date-Time API includes classes
like
Date
,
Calendar
,
GregorianCalendar
, etc. They are in the
java.util
and
java.sql
packages. The
Date
class has
existed since the inception of JDK; others were added in JDK 1.1.
Why did we need a new Date-Time API? The simple answer is that the designers of the legacy Date-Time API did
not get it right in two attempts. To list a few of the problems, some of the issues with the legacy Date-Time API are
•
A date always had two components: a date and a time. If you needed just a date without
any time information, you had no choice. Developers used to set the time to midnight in a
date object to represent a date-only date, which was incorrect for several reasons. The same
argument is valid for storing only time.
•
A datetime was simply stored as the number of milliseconds elapsed since January 1, 1970
midnight UTC.
•
Manipulating dates were as complex as you can think; the
year
field in a
Date
object was
stored as an offset from 1900; months ran from 0 to 11, not from 1 to 12, as humans are used to
conceptualizing them.
•
Legacy Date-Time classes were mutable and therefore not thread-safe.
