News

Java May Get Time and Date Upgrade

• By Joab Jackson
• June 2, 2008

At last month's JavaOne 2008 conference in San Francisco, Stephen Colebourne, an architect for the Switzerland integrator Sita, and Michael Santos, a senior technical consultant at Summa Technologies, presented their work (PDF here) on the Java Specification Request 310, Date and Time Application Programming Interface.

While Java currently has a class to define dates and another class to define time, both have a number of shortcomings, the pair of developers noted. This new API will allow developers to work with dates and time with far more flexibility, they promised.

"There are many meanings of the English word time. It's one of those weird words in the English language that has lots of meanings," Colebourne explained. The new API will offer developers to work within two broad definitions of time. One is continuous time, or machine time. The other is human time.

For continuous time, the API will include a way to record an instant of time, which would be captured as so many units after a predefined epoch. This base of this form of a time is a single number representing some point in time, as referenced from some earlier predefined point in time.

In continuous time, two instances can also be used to create an interval -- or the set of all instances that in between the start and end time. The instances can also be used to create a duration, namely the length of time between two events.

"You will be able to build an instance [that records] a number of seconds or a number of nanoseconds," Santos said. "You will also be able to compare instances, to see if one happens before or after the other. Or you can check to see if an instant appears within an interval."

The second kind of time the API supports, human time, breaks time into a number of recognizable fields, such as the year, month, hour, minute and second. For human time, the API will adopt ISO standard 8601.

In this standard, dates are represented by in the yyy-mm-dd format. In this format, June 2, 2008 would be represented as 2008-06-02. The time of day would be represented in the hh:mm:ss format so that 9:15 a.m. in the U.S. Eastern time zone would be represented as 09:15.00. ISO 8601 also offers an annotation for specifying the offset of this time from universal coordinated time.

In addition to these basic formats, JSR 310 will also offers some features that will resolve some of the more tricky problems programmers face when devising calculations involving dates and time.

One feature, called a resolver, can, when given an incorrect date (i.e., Feb. 30) adjust it to the correct date (e.g., March 1 or March 2, depending on if it is a leap year). Another feature, called an adjuster, can calculate a date given a set of conditions. For instance, it can allow a program to ask what the last day of any given month is.

Another feature adjusts the timestamps that may have gotten botched up by daylight savings rules, which can be helpful in parsing those periods of time when events in two separate hours are recorded as happening in the same hour due to the clock being set back an hour.

Colebourne said the development team is also planning to make the API extensible due to the fact that "there are many ways to manipulate time," he said. For instance, some organizations pay employees every other week, while others pay their people twice a month. Making the API extensible ensures that each organization can manipulate their time data in ways that are specific to their organization.

Another example of extensibility is the calendering system. By default, the API will use the Gregorian calendar system. Other calendars, however, could be entered as a separate date class, such as the Hebrew calendar or the Japanese calendar, as well as historic calendars like the Julian calendar.

"If you know the particular calendar system you want to deal with, then you have a date object that represents just that particular calendar system," Colebourne said.

A JSR is a proposed specification for extending the Java programming language. The JSR could be integrated with the current date/time classes, since the keepers of the Java have no plans to deprecate these classes. The Java Community Process (JCP) program, which manages Java, has made no decision on including JSR 310 into Java 7, the next version of the program language. The developers are seeking other volunteers to help further define the specification.

"We want to make sure this JSR works. We can't afford a third broken date and time API," Colebourne said.