On 10/22/2010 6:13 PM, John Caron wrote:
On 10/22/2010 9:46 AM, Julia Collins wrote:
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" ;
Hi John,
I think the current interpretation in CF -- having time default to UTC
-- is the better one (even without the added value that a change would
be disruptive).
* First -- stating the obvious as part of the baseline of
discussions -- time *is* a simple linear progression -- hour after
hour. It is only Earth processes and human history that steer us
towards encoding times with our complex calendars and peculiar
time encodings. (In this sense ISO date/time strings are a
formatting convenience.) As a generality, minimizing the degree
to which earth processes and history bleed into our simple
encodings of **coordinates** is going to serve our scientific
goals best.
* Formal time zones are a woefully inadequate encoding of solar
positioning information for scientific purposes. Your example of
"raster data which represents values at 0400 local time across
many time zones" (assuming I've understood you correctly) will
have sharp artificial discontinuities at time zone boundaries --
+1/2 hour error on one side and -1/2 hour to the other -- because
time zones are such a crude representation of local (earth
process) time. As Benno pointed out the arbitrary human-defined
squiggles in the time zone definitions make this problem even much
worse. (The fact that ISO 8601 defaults to local time is
yet-another illustration of how most ISO and OGC standards were
originally conceived for purposes OTHER THAN describing scientific
processes that vary in both space and time.)
Should we craft a formal addition to CF that would deal properly with
earth process local (solar) time encoding? A CF file could define a
variable that precisely computed the offset in time based on longitude;
give it a standard_name like "local_solar_time"; and point to it with
an agreed attribute name from the corresponding time coordinate axis.
Simple enough and might be worthwhile. On the other hand, since the
calculation is so simple and identical in every case, maybe this should
just be left to the client to compute.
- Steve
==========================
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/
[email protected]
+1 303.492.6405
This is a fairly unusual use case. Its more likely that someone will
forget to add the time zone, or is relying on past behavior.
Perhaps we need a convention for your specific case?
John
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
