[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.