Re: [netcdf-java] Date precision while aggregating data



Steve Loch wrote:
I find it surprising, as we are debating issues relating to high-precision time,
that the discussion has not mentioned that UTC is periodically adjusted so as to track mean solar time - so that not all days have 86400 seconds in them. Is care taken in the algorithms to insert the intercalary leap seconds at the appropriate points? TAI and GPS (19 seconds apart) don't use leap seconds according to Wikipedia. There
is a (current) proposal to phase out leap seconds in UTC.

Steve Loch

I'm not the best person to answer this. But since no one else answered, I'll do my best and hope that others correct me if I'm wrong.

The Java documentation is a little vague about leap seconds.

The documentation for java.util.Date (http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html) indicates the authors were aware of leap seconds, but leave it to the "the host environment" to support them or not. (That seems like the worst solution.) But Date isn't the most relevant class.

The documentation for GregorianCalendar (http://java.sun.com/j2se/1.5.0/docs/api/java/util/GregorianCalendar.html), which is the class netcdf-java is probably using for much of the Calendar work, shows no awareness of the leap second issue.

I suspect that in almost all installations, Java/GregorianCalendar is unaware of leap seconds. My evidence is that you can take a start date/time, create a GregorianCalendar object, add or subtract any multiple of 86400 seconds (the number of seconds per day), and you get another date with the same time. Comments on different web pages agree.

I don't think this makes Java and GregorianCalendar useless for most date/time work. Java still can accurately store a date/time. There is only trouble if you wish to store a date/time that is a leap second or if you want to calculate the elapsed time between two date/times when there is an intervening leap second. If you need to do that, use another library, or augment Java's answer with your own leap second data.

And if you really need UTC date/times done right (with leap seconds), you probably have to do it all with your own code. I don't know of a Java high-precision time library (that deals with leap seconds).

It isn't an ideal situation.

I hope that is helpful.

Sincerely,

Bob Simons
Satellite Data Product Manager
Environmental Research Division
NOAA Southwest Fisheries Science Center
1352 Lighthouse Ave
Pacific Grove, CA 93950-2079
(831)658-3205
bob.simons@xxxxxxxx

The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric
Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><


  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: