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(?)
Received on Wed Mar 16 2011 - 10:59:59 GMT
