netcdf time (cf-standard) and cdo – in #9: CCLM

in #9: CCLM

<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>

  @rolfzentek in #d24ccd9

<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>

netcdf time (cf-standard) and cdo

RZ wrote

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

View in channel
<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>

  @burkhardtrockel in #5ddee74

<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>
BR replied

“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.

View in channel
<p> Thanks, <br/> it seems cdo will now get an update for this in the next version (1.9.9) </p>

  @rolfzentek in #5a6ed64

<p> Thanks, <br/> it seems cdo will now get an update for this in the next version (1.9.9) </p>
RZ replied

Thanks,
it seems cdo will now get an update for this in the next version (1.9.9)

View in channel
<p> This is good news! Thanks for the info! </p>

  @burkhardtrockel in #6f247b2

<p> This is good news! Thanks for the info! </p>
BR replied

This is good news! Thanks for the info!

View in channel