-
Notifications
You must be signed in to change notification settings - Fork 179
Time truncated on conversion to CalendarDate #73
Comments
What version of netcdf-java are you using? On Sun, Aug 24, 2014 at 11:53 PM, Craig Jones [email protected]
|
Problem occurs in the latest version of Reading ncWMS which uses 4.3.22 and in earlier versions. Code looks the same in master. |
Make that, the code looks the same in other branches - the repository defaulted to target-4.3.22, but the code looks the same in other branches including 4.5.3. Changes which appear to fix this problem for us (in 4.3.17) are: |
Hi Craig: These changes look great. I am adding to 4.3.23 (prob released today) and I appreciate you making these contributions. John On Mon, Aug 25, 2014 at 4:27 PM, Craig Jones [email protected]
|
We are currently having an issue with the embedded ncWMS server in our thredds instance where date/time values reported in the GetCapabilities statement and in Godiva do not reflect the closest date/time to the value recorded in the netcdf dataset. I believe this is an issue with the netcdf java library as explained below, rather than with ncWMS itself. This is also an issue in standalone ncWMS and is causing us issues downstream where we are using the date/time reported by ncWMS for further work (its not just a cosmetic issue).
For example, for the netcdf file
the time value is 23447.104166666664 (days since 1950-01-01 00:00:00 UTC). If I use matlab to calculate the date/time value by adding this duration to the base date, matlab gives me 14-03-13 02:30 which is what we are expecting:
nctools also reports the date/time as 2014-03-13 02:30 :
ggalibert@5-nsp-mel:/mnt/opendap/1/IMOS/opendap/ACORN/gridded_1h-avg-current-map_QC/ROT/2014/03/13$ ncdump -t -v TIME IMOS_ACORN_V_20140313T023000Z_ROT_FV01_1-hour-avg.nc | grep 'TIME = "' TIME = "2014-03-13 02:30" ;
But the embedded ncWMS reports the date/time as 2014-03-13 02:29:99.999:
Debugging this in ncWMS I found that ncWMS uses the ucar.nc2.time.CalendarDate add method to calculate this date/time.
The reason why ucar.nc2.time.CalendarDate add returns 2014-03-13 02:29:99.999 is because it casts the time in milliseconds calculated as a double to a long, in the process truncating it:
it would make more sense to round it to the nearest millisecond as this gives us the closest date/time to the stored double value as follows:
(same applies to other calculations in this method).
Any chance of getting this fixed? I can prepare a pull request if you would like.
The text was updated successfully, but these errors were encountered: