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/
>> collinsj at nsidc.org
>> +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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20101023/b9952666/attachment-0001.html>
Received on Sat Oct 23 2010 - 10:34:29 BST
