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

RE: query about java netcdf libraries and THREDDS



Hi John,
We at BODC are currently using
ncWMS version 1.1.1
TDS version 4.3.18

Regards
Quyen


-----Original Message-----
From: Lowry, Roy K.
Sent: 27 November 2013 20:11
To: John Caron; Gaffney, Sean P.
Cc: Luong, Quyen T.; Jon Blower; address@hidden
Subject: 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.