NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi John, Yes, this is a nice libary. I believe that out of the box it does not understand leap seconds but I think it would be possible to write a Chronology that does handle this (as Roland Schweitzer did for AllLeap and NoLeap calendars). Cheers, Jon On Tue, May 27, 2008 at 5:54 PM, John Caron <caron@xxxxxxxxxxxxxxxx> wrote: > 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@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. >> <>< <>< <>< <>< <>< <>< <>< <>< <>< >> _______________________________________________ >> netcdf-java mailing list >> netcdf-java@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ > _______________________________________________ > netcdf-java mailing list > netcdf-java@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > -- -------------------------------------------------------------- Dr Jon Blower Tel: +44 118 378 5213 (direct line) Technical Director Tel: +44 118 378 8741 (ESSC) Reading e-Science Centre Fax: +44 118 378 6413 ESSC Email: jdb@xxxxxxxxxxxxxxxxxxxx University of Reading 3 Earley Gate Reading RG6 6AL, UK --------------------------------------------------------------
netcdf-java archives: