Thanks Aleksander for pushing in this direction.
This proposal is a very helpful way forward, both for capturing data coming from sensors in an ISO8601 format (a steadily increasing number), and for letting some of us add information in a human-readable format for direct human use. Which, alas, is all many of the existing tools can do, present the format that exists.
And I agree that as it stands it is not a fundamental change of the convention, as you are requesting it. While I wish the coordinate variables could be expressed this way, we likely won't agree on that any time soon.
I would rather not limit the subset of ISO8601 datetime formats, though. There are libraries that support all ISO8601 date-time formats; it is designed to be uniquely recognizable no matter which format is chosen; and trying to define which formats we will and won't support is time not well spent.
On the other hand, we should limit it to only the formats expressing an instance of date/time (meaning single date or date + time), and exclude the range or duration notations from this particular standard name. (Because those are inherently different quantities in different units.) Can add those as needed later.
John
On Mar 19, 2013, at 09:26, Aleksandar Jelenak - NOAA Affiliate <aleksandar.jelenak at noaa.gov> wrote:
> I fully support John Caron's proposal of having ISO 8601 datetime
> strings as another way for encoding time data. But I proposed a
> standard name so would like to return to that.
>
> From a few replies so far it seems that many interpret this standard
> name proposal as a fundamental change of the convention. I don't see
> it that way. My intention was to enhance the interoperability for such
> data by specifying a limited subset of ISO8601 datetime string
> formats. Note that having such variables does not break the convention
> as long as they are not coordinate variables.
>
> Can I have the final decision, please?
>
> -Aleksandar
>
> On Fri, Mar 15, 2013 at 4:39 PM, John Caron <caron at unidata.ucar.edu> wrote:
>> Hi All:
>>
>> Ok, its friday afternoon so ill bite on this, and wax philosophical even
>> before the beer.
>>
>> An insidious mistake is to think that problems should be fixed in software
>> libraries. Actually the deep mistake is to mistake the reference software
>> with the file encoding. Why bother fixing the encoding when a few lines in
>> _your_ software can fix the problem transparently? Ive seen this occur in
>> all three of the great western religious systems of our day: netCDF, HDF and
>> OPeNDAP libraries.
>>
>> Better is to do the encoding of information as cleanly as possible.
>> Post-apocalyptic software engineers who have lost all knowledge of what
>> netCDF and CF mean and are painstakingly uncovering climate archives with
>> their whisk brooms will thank us.
>>
>> "35246 hours since 1970-01-01" isnt just unreadable; it uses a calendar
>> system that may be non-trivial. Calendars are hard; Java has got it wrong
>> already twice, and is now trying for a 3rd time (with jsr 310 in Java 8,
>> based on experience with joda-time).
>>
>> "1974-01-08T14:00:00Z" ( == "35246 hours since 1970-01-01" in the standard
>> calendar) is a better representation of that date. because at least you know
>> what the user thought the damn date was.
>>
>> The good argument for "35246 hours since 1970-01-01" representation, is that
>> given two of them, at least you know what the user thought the damn time
>> interval is between them.
>>
>> Anyway, I think both are good, and should be allowed. Finish your beer and
>> ill order another round.
>>
>> John
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
----------------
John Graybeal <mailto:jgraybeal at ucsd.edu> phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Tue Mar 19 2013 - 10:57:15 GMT
