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: [email protected]
[mailto:[email protected]] On Behalf Of John Caron
Sent: 16 March 2011 17:00
To: [email protected]
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, [email protected] 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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
