Dear All,
I wonder how many existing CF data files would have the meaning of their time channel changed were this suggestion to be adopted.
If I were Julia I would be reworking my data so that the time channel was true UT. I've had so many problems in the past with local time co-ordinates........
Cheers, Roy.
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Julia Collins
Sent: 22 October 2010 16:46
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data (timeas ISO strings)
Hello,
Benno's comment provides a convenient entry point for me to describe a
recent problem.
On Fri, 22 Oct 2010, Benno Blumenthal wrote:
> 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.
To clarify, this is the time zone interpretation used in the current CF
standard.
> If we take that to constrain ISO8601 as well, we have made progress.
> If we can do such a thing.
Actually, I would like to propose the opposite: that CF follow the ISO
standard of interpreting an omitted time zone as *local time*. I have some
raster data which represents values at 0400 local time across many time
zones. The time units that I think make intuitive sense are:
time:units = "days since 1601-01-01T00:00:00" ;
No time zone is indicated, therefore according to the ISO standard I'm
referring to local time. An example time unit for this data set would be
one that decodes to 2007-07-19 04:00. From the ISO point of view, this
means 0400 at local time. From the CF point of view, since a time zone
omission implies UTC, my time value is interpreted as 0400+00:00 (0400
UTC), which is incorrect. The correct UTC value varies over the x axis. If
instead I want to indicate a local time in CF, what local time do I use?
The only place I see to indicate time zone is in the time units string
itself. I haven't figured out a way in CF to describe the zone for each
data point. There's no doubt a way to do this using cells, but that comes
at a cost of complexity. The most elegant solution I see is to follow the
ISO assumptions, which allows me to indicate a generic local time in the
time units string.
Part of my argument for following the ISO approach to time zone
specification is that it is the *ISO* approach. My guess is that when it
comes to time interpretation by a wide audience, ISO is perceived (and
known) as a more general standards body than CF. I don't think it's wise
for CF to constrain ISO. Rather, the established ISO standards should
be constraining CF.
I know that switching to the ISO convention for interpreting the meaning of
an existing (or not) time zone indicator is an unpleasant suggestion, since
it's not backwards compatible in the least. However, I think this is a
change that should be considered. For now, I've resigned myself to
creating files that are not quite CF-compliant.
Julia
--
Julia Collins
National Snow and Ice Data Center
http://nsidc.org/
collinsj at nsidc.org
+1 303.492.6405
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Fri Oct 22 2010 - 10:01:11 BST
