[netcdf-java] Date precision while aggregating data

[John Caron]

Hi Bob, Steve:

Im impressed by the joda date/time library (http://joda-time.sourceforge.net/) and i am likely to start using it. It would be useful to see if it deals with this issue, or can easily be extended to do so.

Bob Simons wrote:
> 
> 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 at noaa.gov
> 
> 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.
> <>< <>< <>< <>< <>< <>< <>< <>< <><
> _______________________________________________
> netcdf-java mailing list
> netcdf-java at unidata.ucar.edu
> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/