This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Cristina, > Now....in our files we have some global attributes: > start_time:Time of the first measurement in the data file > stop_time: Time of the last measurement in the data file > > For that attributes > ---------------------------------------------------------- > we use the format: "hh:mm:ss UTC" > as described in GDS (Version 2.0 revision 0.1) > (http://www.ghrsst.org/modules/documents/documents/GDS-2.0-rev-0.1-Core-L4-product-format-specification.doc) > > ---------------------------------------------------------- > BUT IN GDS 2.0: L4 Specification Version 2.0 Rev: 04 > (http://www.ghrsst.org/modules/documents/documents/GDS2.0_Core_L4_product_format_specification_rev04.1.doc) > > It written that the correct new format is > ISO 8601 string, "yyyymmddThhmmssZ" > The use of "Z" to indicate UTC in time and date strings. > The use of "UTC" is not CF, UDUNITS or ISO 8601 compliant. > ---------------------------------------------------------- > So my question is: do we must change our date/time format? > the "hh:mm:ss UTC" is no more CF compliant? or it is only "no more > advised" but still correct? The attributes "start_time" and "stop_time" are not CF attributes, so CF doesn't address how to represent them. However, it does specify how to represent times used in coordinate variables and for climate models. CF specifies that a time zone may be represented in a time string like the "-6:00" in: "seconds since 1992-10-8 15:15:42.5 -6:00" and CF also says Note: if the time zone is omitted the default is UTC, and if both time and time zone are omitted the default is 00:00:00 UTC. but it never includes "UTC" or "Z" in example times, as far as I can determine. If the GHRSST convention says to use the ISO 8601 time notation and to use "Z" in particular, then I think you have to follow that convention, if you want your data to be correctly interpreted by software that is written to understand data compliant with that convention. What CF specifies doesn't seem relevant in this case, because the attributes "start_time" and "stop_time" are not CF attributes, so CF doesn't address how to represent them. However, it does specify how to represent times used in coordinate variables and for climate models. CF specifies that a time zone may be represented in a time string like the "-6:00" in: "seconds since 1992-10-8 15:15:42.5 -6:00" and CF also says Note: if the time zone is omitted the default is UTC, and if both time and time zone are omitted the default is 00:00:00 UTC. but it never includes "UTC" or "Z" in example times, as far as I can determine. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: BWH-238619 Department: Support netCDF Priority: Normal Status: Closed