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

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
--------------------------------------------------------------


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