It is not really a problem to represent this in CF, just less than pretty. time becomes a function of more than one dimension.
So, if by "local time" you mean that time is such that noon local time has the sun directly overhead, i.e. local time before the railroads established time zones, then we have time(longitude,time) i.e. two dimensions time, longitude, and a variable time which gives UTC for each raster point. (Unless, of course, my physics is a bit off). On the other hand, if you mean local time as in local time zone, then time(longitude,latitude,time) because time zones have a big political component to them (which is time dependent). You can, of course, use two different names for time dimension and time variable, would make things easier to understand. Given that this analyis, while valid, is a bit unusual, seems appropriate that CF can represent it, though not as simply as an image which is uniform in UTC. Benno On Fri, Oct 22, 2010 at 12:32 PM, Julia Collins <colli...@nsidc.org> wrote: > Hi, > > On Fri, 22 Oct 2010, Lowry, Roy K wrote: >> >> I wonder how many existing CF data files would have the meaning of their >> time channel changed were this suggestion to be adopted. > > I am sure many. In some cases it might even make them accurate. :-) At some > level, it's a tradeoff between "breaking" existing data descriptions and > creating a more robust standard. Whether my suggestion creates a more > robust standard or not is up for debate. It does align it more closely with > the ISO standard, and I think there's something to be said for that. > >> 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........ > > It's not data I'm generating, but rather data provided by a PI who has > determined that this is how he wants to present his data. I believe the > idea is to be able to view a wide geographic area over the same effective > local time. It's a composite image. If you can tell me how to represent > these multiple UTC times for one variable using the existing CF > conventions, then I'll try to do so. I believe CF limits me to specifying > one time zone for a particular time dimension. Re-working the data so that > it's broken up into separate time zones would, as I understand it, mean > splitting up the data variable into multiple variables, each with their own > time dimension, which is not what the data provider wants to do. Splitting > the variable would require the user to put the pieces back together in > order to see the image as the data provider intended. As far as I can tell, > following the ISO interpretation of the time zone indicator does exactly > what I need without ambiguity. I'd like to describe the data in a way > that's perfectly compliant with the CF convention, but in this case I don't > see a way to do so. > > Thanks, > 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 > -- Dr. M. Benno Blumenthal be...@iri.columbia.edu International Research Institute for climate and society The Earth Institute at Columbia University Lamont Campus, Palisades NY 10964-8000 (845) 680-4450 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata