An error occurred while using the nc.get.time.series function to get the UTC date.

[PanfengZhang]

An error occurred while using the nc.get.time.series function to get the 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)

library(ncdf4)
library(ncdf4.helpers)

diri = "C:/Rmet/data/slp.mon.ltm.1991-2020.nc"
fin <- nc_open(diri)

nc.get.time.series(fin)
##  [1] "0000-12-30" "0001-01-30" "0001-02-27" "0001-03-30" "0001-04-29"
##  [6] "0001-05-30" "0001-06-29" "0001-07-30" "0001-08-30" "0001-09-29"
## [11] "0001-10-30" "0001-11-29"

ncatt_get(fin, "time")$interpreted_actual_range
## [1] "0001/01/01 00:00:00 - 0001/12/01 00:00:00"

According to the metadata information of the data, it is known that the data started in January, not December.

[pvanlaake]

The file is not properly formatted by NCEP. The data are clearly climatological monthly summaries and the "time" coordinate variable indeed has a "climatology" attribute pointing to the "climatology_bounds" boundary variable. That, and the two days off that you report on, give rise to the following issues:

• ncdf4.helpers does all of its calculations on the (deprecated) gregorian calendar. Around year 0 that leads to 2 days of difference, which you also reported on here and a similar problem was reported here where there is an explanation and a solution with the CFtime package. That solution should solve your issue, but there are more problems...
• The NCEP file adheres to the COARDS convention, where climatological data are recorded as taking place in year 0. That means that the "time" coordinates in this file are 1 year off and well-behaved netCDF readers will thus not recognise the data as a climatology. Fine, who cares... but read on.
• The "time" coordinate values are negative, being many hours before 1800-01-01. The "climatology_bounds" boundary values, on the other hands, are positive, and most likely represents timestamps in the middle of the 1991-2020 range. We'll see about that in a bit. CFtime will choke on this creative encoding. It's interesting to note that the "climatology" attribute is from the CF Metadata Conventions, not COARDS, so we have a mix-up here.

Dumping the file contents with ncdump I get this (very much abbreviated):

ncdump "~/slp.mon.ltm.1991-2020.nc"
netcdf slp.mon.ltm.1991-2020 {
dimensions:
        lon = 144 ;
        lat = 73 ;
        time = 12 ;
        nbnds = 2 ;
variables:
[...]
        double time(time) ;
                time:long_name = "Time" ;
                time:delta_t = "0000-01-00 00:00:00" ;
                time:standard_name = "time" ;
                time:axis = "T" ;
                time:units = "hours since 1800-01-01 00:00:0.0" ;
                time:avg_period = "0030-00-00 00:00:00" ;
                time:prev_avg_period = "0000-01-00 00:00:00" ;
                time:climatology = "climatology_bounds" ;
                time:climo_period = "1991/01/01 - 2020/12/31" ;
                time:actual_range = -15769752., -15761736. ;
                time:ltm_range = 1674264., 1936512. ;
                time:interpreted_actual_range = "0001/01/01 00:00:00 - 0001/12/01 00:00:00" ;
[...]
data:

 time = -15769752, -15769008, -15768336, -15767592, -15766872, -15766128, 
    -15765408, -15764664, -15763920, -15763200, -15762456, -15761736 ;

 climatology_bounds =
  1674264, 1928472,
  1675008, 1929216,
  1675680, 1929912,
  1676424, 1930656,
  1677144, 1931376,
  1677888, 1932120,
  1678608, 1932840,
  1679352, 1933584,
  1680096, 1934328,
  1680816, 1935048,
  1681560, 1935792,
  1682280, 1936512 ;
}

If I use the raw coordinate values in CFtime I get this:

CFtime("hours since 1800-01-01T00:00:00.0", "standard", 
               c(-15769752, -15769008, -15768336, -15767592, -15766872, -15766128, 
                 -15765408, -15764664, -15763920, -15763200, -15762456, -15761736))
#> CF calendar:
#>   Origin  : 1800-01-01T00:00:00
#>   Units   : hours
#>   Type    : standard
#> Time series:
#>   Elements: [0001-01-01 .. 0001-12-01] (average of 728.727273 hours between 12 elements)
#>   Bounds  : not set

Just as you would expect it. But wrong nevertheless. The boundary values:

bnds <- matrix(c(1674264, 1928472,
                 1675008, 1929216,
                 1675680, 1929912,
                 1676424, 1930656,
                 1677144, 1931376,
                 1677888, 1932120,
                 1678608, 1932840,
                 1679352, 1933584,
                 1680096, 1934328,
                 1680816, 1935048,
                 1681560, 1935792,
                 1682280, 1936512), nrow = 2)

# Lower bounds
CFtime("hours since 1800-01-01T00:00:00.0", "standard", bnds[1,])
#> CF calendar:
#>   Origin  : 1800-01-01T00:00:00
#>   Units   : hours
#>   Type    : standard
#> Time series:
#>   Elements: [1991-01-01 .. 1991-12-01] (average of 728.727273 hours between 12 elements)
#>   Bounds  : not set

# Upper bounds
CFtime("hours since 1800-01-01T00:00:00.0", "standard", bnds[2,])
#> CF calendar:
#>   Origin  : 1800-01-01T00:00:00
#>   Units   : hours
#>   Type    : standard
#> Time series:
#>   Elements: [2020-01-01 .. 2020-12-01] (average of 730.909091 hours between 12 elements)
#>   Bounds  : not set

Wrong again, at least when using the CF Metadata Conventions. The lower boundaries are ok, but the upper boundaries do not include the final month! In other words, for January the upper bound should not be 1 January 2020 but 1 February 2020 (such that all of January 2020 is included).

In conclusion, NCEP should improve its netCDF encoding to adhere to common conventions.

[PanfengZhang]

Thanks for your detailed explanation.  张盼峰-------- 原始邮件 --------发件人： Patrick ***@***.***>日期： 2025年7月10日周四 19:23收件人： "pacificclimate/ncdf4.helpers" ***@***.***>抄送： Panfeng Zhang ***@***.***>, Author ***@***.***>主 题： Re: [pacificclimate/ncdf4.helpers] An error occurred while using the nc.get.time.series function to get the UTC date. (Issue #10)pvanlaake left a comment (pacificclimate/ncdf4.helpers#10) The file is not properly formatted by NCEP. The data are clearly climatological monthly summaries and the "time" coordinate variable indeed has a "climatology" attribute pointing to the "climatology_bounds" boundary variable. That, and the two days off that you report on, give rise to the following issues: ncdf4.helpers does all of its calculations on the (deprecated) gregorian calendar. Around year 0 that leads to 2 days of difference, which you also reported on here and a similar problem was reported here where there is an explanation and a solution with the CFtime package. That solution should solve your issue, but there are more problems...The NCEP file adheres to the COARDS convention, where climatological data are recorded as taking place in year 0. That means that the "time" coordinates in this file are 1 year off and well-behaved netCDF readers will thus not recognise the data as a climatology. Fine, who cares... but read on.The "time" coordinate values are negative, being many hours before 1800-01-01. The "climatology_bounds" boundary values, on the other hands, are positive, and most likely represents timestamps in the middle of the 1991-2020 range. We'll see about that in a bit. CFtime will choke on this creative encoding. It's interesting to note that the "climatology" attribute is from the CF Metadata Conventions, not COARDS, so we have a mix-up here. Dumping the file contents with ncdump I get this (very much abbreviated): ncdump "~/slp.mon.ltm.1991-2020.nc" netcdf slp.mon.ltm.1991-2020 { dimensions: lon = 144 ; lat = 73 ; time = 12 ; nbnds = 2 ; variables: [...] double time(time) ; time:long_name = "Time" ; time:delta_t = "0000-01-00 00:00:00" ; time:standard_name = "time" ; time:axis = "T" ; time:units = "hours since 1800-01-01 00:00:0.0" ; time:avg_period = "0030-00-00 00:00:00" ; time:prev_avg_period = "0000-01-00 00:00:00" ; time:climatology = "climatology_bounds" ; time:climo_period = "1991/01/01 - 2020/12/31" ; time:actual_range = -15769752., -15761736. ; time:ltm_range = 1674264., 1936512. ; time:interpreted_actual_range = "0001/01/01 00:00:00 - 0001/12/01 00:00:00" ; [...] data: time = -15769752, -15769008, -15768336, -15767592, -15766872, -15766128, -15765408, -15764664, -15763920, -15763200, -15762456, -15761736 ; climatology_bounds = 1674264, 1928472, 1675008, 1929216, 1675680, 1929912, 1676424, 1930656, 1677144, 1931376, 1677888, 1932120, 1678608, 1932840, 1679352, 1933584, 1680096, 1934328, 1680816, 1935048, 1681560, 1935792, 1682280, 1936512 ; } If I use the raw coordinate values in CFtime I get this: CFtime("hours since 1800-01-01T00:00:00.0", "standard", c(-15769752, -15769008, -15768336, -15767592, -15766872, -15766128, -15765408, -15764664, -15763920, -15763200, -15762456, -15761736)) #> CF calendar: #> Origin : 1800-01-01T00:00:00 #> Units : hours #> Type : standard #> Time series: #> Elements: [0001-01-01 .. 0001-12-01] (average of 728.727273 hours between 12 elements) #> Bounds : not set Just as you would expect it. But wrong nevertheless. The boundary values: bnds <- matrix(c(1674264, 1928472, 1675008, 1929216, 1675680, 1929912, 1676424, 1930656, 1677144, 1931376, 1677888, 1932120, 1678608, 1932840, 1679352, 1933584, 1680096, 1934328, 1680816, 1935048, 1681560, 1935792, 1682280, 1936512), nrow = 2) # Lower bounds CFtime("hours since 1800-01-01T00:00:00.0", "standard", bnds[1,]) #> CF calendar: #> Origin : 1800-01-01T00:00:00 #> Units : hours #> Type : standard #> Time series: #> Elements: [1991-01-01 .. 1991-12-01] (average of 728.727273 hours between 12 elements) #> Bounds : not set # Upper bounds CFtime("hours since 1800-01-01T00:00:00.0", "standard", bnds[2,]) #> CF calendar: #> Origin : 1800-01-01T00:00:00 #> Units : hours #> Type : standard #> Time series: #> Elements: [2020-01-01 .. 2020-12-01] (average of 730.909091 hours between 12 elements) #> Bounds : not set Wrong again, at least when using the CF Metadata Conventions. The lower boundaries are ok, but the upper boundaries do not include the final month! In other words, for January the upper bound should not be 1 January 2020 but 1 February 2020 (such that all of January 2020 is included). In conclusion, NCEP should improve its netCDF encoding to adhere to common conventions. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>