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/ colli...@nsidc.org +1 303.492.6405 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata