Hi again,
I must admit that your data is very different to the types of data I work with and I don't fully understand issues with composite images. Typical data for me are time series where a series of parameters, including position are logged every 30 seconds or so as a ship sails along. Years ago I had a dataset where a form of local time (ship's time) was used and they switched from daylight saving part way through the cruise. Result was that according to the data the ship was in two different places at a given time: not good. If a ship sails across the Atlantic, we don't want the time channel jumping around as time zone boundaries are crossed. We have a lot of this type of data assembled over the past 30 years - not just ships but also moored instruments - with elapsed time channels that are assumed to be UT and have put much effort in the past into the conversion of any incoming local times in both data and metadata to UT. To suddenly have this interpreted as local wouldn't improve the accuracy of anything!
Making the default CF time local might make the standard appear more robust for your data world but not for mine. Alignment with ISO standards is an essential requirement for the development of new conventions, but I don't feel retrospective adoption to be a prudent path.
Cheers, Roy.
________________________________________
From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Julia Collins [collinsj at nsidc.org]
Sent: 22 October 2010 17:32
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Interpretation of unspecified time zone (was: New standard names for satellite obs data (timeas ISO strings))
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/
collinsj at nsidc.org
+1 303.492.6405
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Fri Oct 22 2010 - 12:10:41 BST
