How about the following: if we want to add fixed durations to the temporal datum, we use the current syntax:
"duration since datum"
as we do currently. But if we want to add calendar fields to the datum we use:
"field_name since datum by calendar field"
or something similar? So:
"days since 1800-1-1"
would be a standard time axis adding multiples of 24*60*60 seconds to the datum. But
"days since 1800-1-1 by calendar field"
would simply increment the days field of the calendar in question (they could be different because of leap seconds in UTC). It's possible that a "by calendar field" time axis would be constrained to integer values as John suggests, but I haven't thought this through.
This proposal keeps backward compatibility with UDUNITS and the current interpretations in CF, and doesn't require us to allow string values in time coordinates.
As others have pointed out we also need to think about temporal resolution. Perhaps we could adopt a convention whereby the number of fields in the temporal datum string indicates the resolution? So
"years since 1800"
would implicitly be at yearly resolution.
Sorry, two ideas in one there, but they are related.
Jon
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of John Caron
Sent: 16 March 2011 17:00
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
On 3/16/2011 9:39 AM, John Caron wrote:
> On 3/15/2011 1:30 PM, tim.nightingale at stfc.ac.uk wrote:
>> Dear All,
>>
>> At the nit-picking level, "day" (and "hour" and "minute") are not
>> necessarily stable units either, because of the occasional appearance
>> of leap seconds. While this won't be of much concern for many users,
>> it can be important for precisely timed data.
>
> Hi Tim:
>
> My understanding is that there are some calendars that handle this
> better than "standard". the java packages im looking at refers to UTC
> and TAI as more accurate possibilities:
>
> http://en.wikipedia.org/wiki/Coordinated_Universal_Time
>
> http://en.wikipedia.org/wiki/International_Atomic_Time
>
> im not clear on the issues, but it seems like we could add those
> calendars if needed.
>
> John
I think that this has more implications than i realized.
Suppose we added the UTC_Calendar to CF, which tracks leap seconds etc.
So if one had the time coordinate "days since 1800-01-01" with values =
"0,1,2,3..." and we need the resulting coordinates to be "1800-01-01",
"1800-01-02", "1800-01-03", "1800-01-04",.... which in this calendar
gives an uneven number of seconds between coordinates.
So all timeUnits (except seconds) now mean "increment the calendar
field", not "add x secs to base", that is, its calendar dependent if any
timeUnit implies a fixed number of seconds.
In that case, then fractional values may not make sense(?)
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Mar 16 2011 - 11:13:42 GMT
