[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[UDUNITS #BWH-238619]: date-time format

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