On 3/16/2011 11:13 AM, Jon Blower wrote:
> 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 would be ok, and perhaps forbid month/year in the udunits. removing
fractions in the "by calendar field" would make life a lot easier.
> 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.
could someone define what resolution means ?
>
> 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:30:11 GMT
