On Aug 19, 2011, at 4:12 PM, Karl Taylor wrote:
> Hi all,
>
> My understanding is that leap-seconds are inserted so that the calendar remains (almost) perfectly synchronized with the seasons. If, under the CF convention, leap seconds are ignored and time is recorded as, say, "days since 2007", and two times were recorded, 0.5 and 365.5, those times would correspond to 12 noon of Jan 1, 2007 and 12 noon of Jan 1, 2008. If, however, the CF calendar were required to be truly realistic, the leap second which in fact was inserted at the end of 2007 would mean the second time should be 11:59:59 of Jan 1, 2008.
>
> I am pretty sure that the vast majority of datasets stored under the CF convention will not take into account leap seconds and will record times assuming they are not there. I think it is unrealistic to assume users will adhere to a truly realistic calendar when recording their times. In the above example, if the measurements were made at noon of each day, then you would have to record times of 0.5 and 365.5+1./(24*60*60) = 365.500011574 (rather than 0.5 and 365.5).
>
> I therefore think the CF convention should specify that the times recorded in files should be interpreted according to the specified calendar, but assuming that leap-seconds have been ignored.
I can't disagree with your reasoning as existing datasets in CF are likely dominated by model outputs. I should mention that it may cause some consternation among folks who are just now struggling to make more satellite data available in CF. The implication to them will be that they need to uncorrect (oops, not a word according to spellcheck) the leap seconds in their data in order to be truly CF-compliant. (This won't be an issue with Level 3 data, but we were just starting to make progress with Level 1 and Level 2 data...)
Perhaps there could be an attribute we could set that says whether we have accounted for leap seconds? With the absence of such an attribute to be presumed as meaning leap seconds have been ignored.
>
> cheers,
> Karl
>
>
> On 8/19/11 9:28 AM, John Caron wrote:
>> On 8/19/2011 7:48 AM, Lynnes, Christopher S. (GSFC-6102) wrote:
>>
>>> On Aug 19, 2011, at 7:54 AM, Jon Blower wrote:
>>>
>>>
>>>> Hi Chris,
>>>>
>>>> Does the calendar system usually define whether leap-seconds are taken into account or not?
>>>>
>>> Generally speaking, I don't believe so, if only because calendar systems usually go down to the day granularity. Seconds-based doordinate time standards, such as UTC and TAI do, because they have to. Julian date (NOT the day of year many associate with the name) is an exception, with its fractional dates.
>>>
>>>
>>>> In other words, given knowledge of which calendar system is in use, could a library make the correct calculation? Or is other information needed too?
>>>>
>> In my limited understanding, a calendar system might track leap seconds
>> or not. If it does, then all calendar fields (except seconds and
>> millisecs) would be variable length. But for any given calendar, the
>> interval (in seconds) between two valid dates would be well defined. Of
>> course, these intervals will differ between calendars.
>>
>> Therefore, one can talk about a "correct" implementation of a calendar
>> system, and one can talk about the difference between two calendar
>> systems, one of which is the correct one to use in some context.
>> Otherwise, im not sure there really is a "correct calculation", or at
>> least that might be a confusing way to state the issue.
>> _______________________________________________
>> CF-metadata mailing list
>>
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185
Received on Fri Aug 19 2011 - 15:38:50 BST
