Our site saves small pieces of text information (cookies) on your
device in order to verify your login. These cookies are essential
to provide access to resources on this website and it will not
work properly without.
Learn more
<p>
Hello,
</p>
<p>
so a new cclm version and a new cdo seem to be incompatable.
</p>
<p>
First: Can anyone please confirm this problem?
</p>
<p>
use cdo 1.9.6 (or later) and do a “cdo info lffdYYYYMMDDHH.nc” on a file with a simulation start of
<span class="caps">
NOT
</span>
00:00:00
<span class="caps">
UTC
</span>
(and a new cclm version)
<br/>
this should show the wrong time.
</p>
<p>
in our case we have an old cclm output file with:
<br/>
[netcdf] time:units = “seconds since 2015-12-31 18:00:00Z“
<br/>
[cdo] processes time correctly
</p>
<p>
and a new cclm (clm16) output with:
<br/>
[netcdf] time:units = “seconds since 2015-12-31T18:00:00Z“
<br/>
[cdo] from 1.9.6 (and later)all times shown are -18h; cdo seems to break at the T and igore the 18:00:00 / assume 00:00:00
</p>
<p>
———————
</p>
<p>
I posted it as a bug in the cdo forum, but Uwe Schulzweide said that the NetCDF CF-Standard only allows for a space between date and time.
<br/>
I tried to check the CF-Standard but have not found a clear statement on this…
</p>
<p>
(Assuming someone else can confirm this incompatability) Any netcdf cf-standard experts out there? Is this a bug/old-cf-convention in cclm?
<br/>
[the http://cfconventions.org/compliance-checker.html doesn´t seem to help… no errors show up for “time” even if I put in a file with “seconds since 2015-12-31ABC18:00:00Z”]
</p>
<p>
Cheers
<br/>
Rolf
</p>
<p>
Hello,
</p>
<p>
so a new cclm version and a new cdo seem to be incompatable.
</p>
<p>
First: Can anyone please confirm this problem?
</p>
<p>
use cdo 1.9.6 (or later) and do a “cdo info lffdYYYYMMDDHH.nc” on a file with a simulation start of
<span class="caps">
NOT
</span>
00:00:00
<span class="caps">
UTC
</span>
(and a new cclm version)
<br/>
this should show the wrong time.
</p>
<p>
in our case we have an old cclm output file with:
<br/>
[netcdf] time:units = “seconds since 2015-12-31 18:00:00Z“
<br/>
[cdo] processes time correctly
</p>
<p>
and a new cclm (clm16) output with:
<br/>
[netcdf] time:units = “seconds since 2015-12-31T18:00:00Z“
<br/>
[cdo] from 1.9.6 (and later)all times shown are -18h; cdo seems to break at the T and igore the 18:00:00 / assume 00:00:00
</p>
<p>
———————
</p>
<p>
I posted it as a bug in the cdo forum, but Uwe Schulzweide said that the NetCDF CF-Standard only allows for a space between date and time.
<br/>
I tried to check the CF-Standard but have not found a clear statement on this…
</p>
<p>
(Assuming someone else can confirm this incompatability) Any netcdf cf-standard experts out there? Is this a bug/old-cf-convention in cclm?
<br/>
[the http://cfconventions.org/compliance-checker.html doesn´t seem to help… no errors show up for “time” even if I put in a file with “seconds since 2015-12-31ABC18:00:00Z”]
</p>
<p>
Cheers
<br/>
Rolf
</p>
so a new cclm version and a new cdo seem to be incompatable.
First: Can anyone please confirm this problem?
use cdo 1.9.6 (or later) and do a “cdo info lffdYYYYMMDDHH.nc” on a file with a simulation start of
NOT
00:00:00
UTC
(and a new cclm version)
this should show the wrong time.
in our case we have an old cclm output file with:
[netcdf] time:units = “seconds since 2015-12-31 18:00:00Z“
[cdo] processes time correctly
and a new cclm (clm16) output with:
[netcdf] time:units = “seconds since 2015-12-31T18:00:00Z“
[cdo] from 1.9.6 (and later)all times shown are -18h; cdo seems to break at the T and igore the 18:00:00 / assume 00:00:00
———————
I posted it as a bug in the cdo forum, but Uwe Schulzweide said that the NetCDF CF-Standard only allows for a space between date and time.
I tried to check the CF-Standard but have not found a clear statement on this…
(Assuming someone else can confirm this incompatability) Any netcdf cf-standard experts out there? Is this a bug/old-cf-convention in cclm?
[the http://cfconventions.org/compliance-checker.html doesn´t seem to help… no errors show up for “time” even if I put in a file with “seconds since 2015-12-31ABC18:00:00Z”]
<p>
“seconds since 2015-12-31 18:00:00Z” follows the
<span class="caps">
ISO
</span>
8601 standard for time formatting.
<br/>
https://de.wikipedia.org/wiki/ISO_8601
</p>
<p>
The CF-Conventions does not provide a mandatory format. Actually, in https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html you can find also an example that follows the
<span class="caps">
ISO
</span>
8601 standard:
<br/>
Example 5.7. Lambert conformal projection
time:units = “hours since 2004-06-23T22:00:00Z”;
</p>
<p>
Therefore it is a problem in
<span class="caps">
CDO
</span>
.
<br/>
Since we start climate simulations generally at 00UTC, this does not harm.
<br/>
If you really want to start at 18
<span class="caps">
UTC
</span>
, the only work around is to replace the T by a blank in netcdf_io.f90 at about line 1900 and create a new executable.
</p>
<p>
“seconds since 2015-12-31 18:00:00Z” follows the
<span class="caps">
ISO
</span>
8601 standard for time formatting.
<br/>
https://de.wikipedia.org/wiki/ISO_8601
</p>
<p>
The CF-Conventions does not provide a mandatory format. Actually, in https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html you can find also an example that follows the
<span class="caps">
ISO
</span>
8601 standard:
<br/>
Example 5.7. Lambert conformal projection
time:units = “hours since 2004-06-23T22:00:00Z”;
</p>
<p>
Therefore it is a problem in
<span class="caps">
CDO
</span>
.
<br/>
Since we start climate simulations generally at 00UTC, this does not harm.
<br/>
If you really want to start at 18
<span class="caps">
UTC
</span>
, the only work around is to replace the T by a blank in netcdf_io.f90 at about line 1900 and create a new executable.
</p>
“seconds since 2015-12-31 18:00:00Z” follows the
ISO
8601 standard for time formatting.
https://de.wikipedia.org/wiki/ISO_8601
The CF-Conventions does not provide a mandatory format. Actually, in https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html you can find also an example that follows the
ISO
8601 standard:
Example 5.7. Lambert conformal projection
time:units = “hours since 2004-06-23T22:00:00Z”;
Therefore it is a problem in
CDO
.
Since we start climate simulations generally at 00UTC, this does not harm.
If you really want to start at 18
UTC
, the only work around is to replace the T by a blank in netcdf_io.f90 at about line 1900 and create a new executable.
netcdf time (cf-standard) and cdo
Hello,
so a new cclm version and a new cdo seem to be incompatable.
First: Can anyone please confirm this problem?
use cdo 1.9.6 (or later) and do a “cdo info lffdYYYYMMDDHH.nc” on a file with a simulation start of NOT 00:00:00 UTC (and a new cclm version)
this should show the wrong time.
in our case we have an old cclm output file with:
[netcdf] time:units = “seconds since 2015-12-31 18:00:00Z“
[cdo] processes time correctly
and a new cclm (clm16) output with:
[netcdf] time:units = “seconds since 2015-12-31T18:00:00Z“
[cdo] from 1.9.6 (and later)all times shown are -18h; cdo seems to break at the T and igore the 18:00:00 / assume 00:00:00
———————
I posted it as a bug in the cdo forum, but Uwe Schulzweide said that the NetCDF CF-Standard only allows for a space between date and time.
I tried to check the CF-Standard but have not found a clear statement on this…
(Assuming someone else can confirm this incompatability) Any netcdf cf-standard experts out there? Is this a bug/old-cf-convention in cclm?
[the http://cfconventions.org/compliance-checker.html doesn´t seem to help… no errors show up for “time” even if I put in a file with “seconds since 2015-12-31ABC18:00:00Z”]
Cheers
Rolf
“seconds since 2015-12-31 18:00:00Z” follows the ISO 8601 standard for time formatting.
https://de.wikipedia.org/wiki/ISO_8601
The CF-Conventions does not provide a mandatory format. Actually, in https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html you can find also an example that follows the ISO 8601 standard:
Example 5.7. Lambert conformal projection time:units = “hours since 2004-06-23T22:00:00Z”;
Therefore it is a problem in CDO .
Since we start climate simulations generally at 00UTC, this does not harm.
If you really want to start at 18 UTC , the only work around is to replace the T by a blank in netcdf_io.f90 at about line 1900 and create a new executable.
Thanks,
it seems cdo will now get an update for this in the next version (1.9.9)
This is good news! Thanks for the info!