Closed PanfengZhang closed 4 months ago
Hi @PanfengZhang ,
I think you should get consistent results with type="s"
and type="n"
. The "n" option shows the numeric values of year, month, day, etc., which should match the strings from the "s" option.
With type="c"
, the conversion uses the udunits2 library to convert the time values to units of "seconds since 1970-01-01 00:00:00 +00:00", which is the reference date for POSIXct. Unfortunately, udunits2 and R interpret the resulting time values using different calendars, so when R displays the times as strings, the dates appear inconsistent.
This is not strictly a bug in RNetCDF or udunits2, because there is no general agreement on time conversions before the Gregorian calendar came into operation in year 1582. For more explanation, please see https://docs.unidata.ucar.edu/udunits/current/udunits2lib.html#Time (along with the R help for utcal.nc
).
You can workaround the problem by converting the times using as.POSIXct
as follows:
> as.POSIXct(utcal.nc(time_units, time, type = "s"))
[1] "0001-01-01 LMT" "0001-02-01 LMT" "0001-03-01 LMT" "0001-04-01 LMT"
[5] "0001-05-01 LMT" "0001-06-01 LMT" "0001-07-01 LMT" "0001-08-01 LMT"
[9] "0001-09-01 LMT" "0001-10-01 LMT" "0001-11-01 LMT" "0001-12-01 LMT"
When R displays the above times as strings, they match the strings passed in. However, the numeric values of the times (in seconds since 1970) will be different from those produced by udunits2.
Thank you for your detailed answer.
An error occurred while using the utcal.nc function to converte the time amounts to UTC date.
The example of .nc data is from NCEP (https://psl.noaa.gov/thredds/fileServer/Datasets/ncep.reanalysis/Monthlies/surface/slp.mon.ltm.1991-2020.nc)
When the type parameter is set to n or s, the returned dates are inconsistent. According to the metadata information of the data, it is known that it is correct when setting s.