RE: query about java netcdf libraries and THREDDS

Hi John,

SeaDataNet, against my advice (I was pushing the BODC standard with an
origin in the 18th century), adopted CJD as the binary time standard.
If the model data BODC serves is going to interoperate with SeaDataNet
observed data without messy time conversions then we're stuck with
it. Your help finding a workaround for the resulting issues is very
much appreciated.

Cheers, Roy.
________________________________________
From: John Caron [address@hidden]
Sent: 27 November 2013 19:43
To: Gaffney, Sean P.
Cc: Lowry, Roy K.; Luong, Quyen T.; Jon Blower; address@hidden
Subject: Re: query about java netcdf libraries and THREDDS

Hi Sean:

First, what version TDS and ncWMS are you using?

Second, if you can send me a sample file, it is easier for me to run it
through the software, and ill see if i can reproduce the problem.

Further, "days since -4713-01-01 00:00:00" is a very bad choice IMO of a
reference date, as gregorian calendar has problems going that far back.
We use standard java date library "joda-time" (which will become the
standard java date parsing in java 8), and basically follow its lead, so
that we dont have to be experts ourselves.

Ive talked to Roy and SeaDataNet about this choice, and they seem to
agree they would do it differently if they were starting over. Anyway, I
would recommend that you not use it if you have a choice, as its just
trouble. Just using a reference date after 1600 or so is all thats
needed. If this is modern data, I cant think of any reason not to use a
modern date like 1970.

Having said that, Im sure we can figure out the problem and a workaround.

John


On 11/27/2013 8:34 AM, Gaffney, Sean P. wrote:
> Hi John,
> Sean Gaffney from BODC here. Roy Lowry suggested I get in touch with you
> in respect of an issue I’m having. We at BODC have been sent a set of CF
> compliant netcdf numerical model data which have time attributes of
> time:units = "days since -4713-01-01 00:00:00" ;
> time:calendar = " gregorian" ;
> This gives us time values which run from 2438396.5 to 2438761.5, which
> are equivalent to (in UT) 12:00 01/01/1964 to 12:00 31/12/2004.
> We told the originator to supply the time in these units so that the
> data would be interoperable with the SeaDataNet community we serve here
> in Europe, as they use this time standard.
> The problem occurs in that our numerical model delivery system runs in
> conjunction with some ncWMS visualisation software developed by Jon
> Blower at Reading. When the data are visualised, the time element
> becomes junk, giving values of 11000 for year. I’ve been in discussion
> with Jon and an associate of his from Reading, Guy Griffiths, and they
> informed us that the “Java-NetCDF libraries do not interpret ISO8601
> dates before 0AD correctly, so if the calendar is set to "standard",
> "gregorian", or is missing, they will not be interpreted correctly”.
> Roy says that you are the person to talk to about these libraries so I
> was wondering could you provide any insight into what is happening with
> the interpretation of the time units as we supply them?
> There is an additional oddity in that, within THREDDS itself, which is
> what we use for interrogating the netcdf files, the times are recognised
> correctly and converted somehow to the right date and time in UT (see
> attached PNG). Neither ourselves nor Guy Griffiths at Reading understand
> where in the THREDDS software this translation occurs, so if you could
> throw some light on this for me as well, I’d greatly appreciate it.
> Thanks very much
> Sean Gaffney
> BODC
>
> _  ________________________________ _
> This message (and any attachments) is for the recipient only. NERC is
> subject to the Freedom of Information Act 2000 and the contents of this
> email and any reply you make may be disclosed by NERC unless it is
> exempt from release under the Act. Any material supplied to NERC may be
> stored in an electronic records management system.

This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.