It appears that when you use the NetCDF Java API's DateUnit.makeDate()
method what is returned is a Date that's correct but offset to the
local time zone. To wit the time units in one of my NetCDF files is
"months since 1900-01-01 00:00:00". When a DateUnit object is
instantiated using this time unit string as the constructor argument
and then its makeDate() method is called to create a Date using 0 as
the argument I don't get "Mon Jan 01 00:00:00 GMT 1900" as expected
but instead "Sun Dec 31 19:00:00 EST 1899". So even though the time
unit defaults to UTC/GMT (according to the latest CF document this is
the default behavior if no time zone is specified in the time units)
the DateUnit class operates using the local/default time zone and
there doesn't appear to be a way to modify this behavior, i.e. no
DateUnit.setTimeZone() method is available, and hence the makeDate()
method is of limited utility since the Dates returned are in the local
time zone rather than in UTC/GMT as expected.
My code looks like this:
DateUnit dateUnit = new DateUnit(inputTimeUnits.getStringValue());
Date initialDate = dateUnit.makeDate(inputTimeArray.getInt(0));
I'd like to be able to use Date objects from the time variable values
but this time zone offset issue makes things a bit cumbersome. Can
anyone advise as to the best way to work around this? Am I missing
something obvious? Maybe there's an easy way to convert the Date
objects to the expected/original time zone?
Thanks in advance for any comments or suggestions.
--James
