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" ;
>
> 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
Received on Fri Oct 22 2010 - 16:13:01 BST
