Yes, TAI is an epochal time, number of seconds since a reference time. In EOSDIS, folks often use TAI93, number of seconds since 01 January 1993 00:00:00.
We have tools that translate between TAI93 and UTC, which rely on an external file (leapsec.dat) to compute the time conversions. On Aug 23, 2011, at 8:47 AM, Jim Biard wrote: > Hi. > > According to the almighty Wikipedia ;), UTC is "a time standard based on > International Atomic Time (TAI) with leap seconds added at irregular > intervals to synchronize with the Earth's rotation." So TAI doesn't attempt > to stay synchronized with the Earth's rotation. > > Another quote from the Wikipedia article on UTC states > UTC is a discontinuous timescale, so it is not possible to compute the exact > time interval elapsed between two UTC timestamps without consulting a table > that describes how many leap seconds occurred during that interval. > Therefore, many scientific applications that require precise measurement of > long (multi-year) intervals use TAI instead. > I'm not advocating for anything, just contributing some factoids. > > Grace and peace, > > Jim Biard > > On 8/23/2011 8:13 AM, Lynnes, Christopher S. (GSFC-6102) wrote: >> On Aug 22, 2011, at 6:36 PM, John Caron wrote: >> >> >>> On 8/22/2011 6:37 AM, Jonathan Gregory wrote: >>> >>>> Dear Chris >>>> >>>> >>>>> 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. >>>>> >>>> Perhaps the real-world calendars with and without leap seconds should be >>>> regarded as two different calendars, since they have different encodings >>>> (meaning decoding/encoding as YMD HMS<-> time-interval since >>>> reference-time). >>>> The "true" real-world calendar is the one with leap seconds. >>>> >>>> CF has a calendar >>>> proleptic_gregorian >>>> >>>> A Gregorian calendar extended to dates before 1582-10-15. That is, a >>>> year is a leap year if either (i) it is divisible by 4 but not by 100 or >>>> (ii) it is divisible by 400. >>>> >>>> What if we clarified this calendar as not having leap seconds? Then it >>>> could >>>> be used for real-world applications for recent dates meaning that it was >>>> just >>>> like the real world except that it doesn't have leap seconds. >>>> >>>> Model calendars, which are already idealised wrt length of year, don't have >>>> leap seconds anyway, I am sure. >>>> >>>> Best wishes >>>> >>>> Jonathan >>>> _______________________________________________ >>>> CF-metadata mailing list >>>> >>>> CF-metadata@cgd.ucar.edu >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> I agree that a separate calendar is needed if we want to have leap >>> seconds. I think the common form is UTC (or TAI?). Chris, what does the >>> satellite community use? >>> >> Both UTC and TAI, actually. >> >> >>> _______________________________________________ >>> CF-metadata mailing list >>> >>> CF-metadata@cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> Christopher Lynnes >> Goddard Earth Sciences Data and Information Center, NASA/GSFC >> 301-614-5185 >> >> _______________________________________________ >> CF-metadata mailing list >> >> CF-metadata@cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > Jim Biard > > Government Contractor, STG Inc. > Remote Sensing and Applications Division (RSAD) > National Climatic Data Center > 151 Patton Ave. > Asheville, NC 28801-5001 > > > jim.bi...@noaa.gov > > 828-271-4900 > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
