Current CDF_Epoch time scheme is nominally continuous Gregorian time from 0AD with no leap seconds or defined coordinate system. In practice, it generally holds UTC times, but leap seconds are overloaded onto the first second of the next day. Also mission data generally have ill-defined times, sometimes including leap seconds and sometimes only UTC at start of mission with no leap seconds afterwards. Science data should have well-defined times to enable more accurate cross-comparison between missions and as documentation for future archive use. The leap second issue does not generally affect data before 1972.

The CDF project currently supports specialized time variables: CDF_EPOCH (8-byte float) and CDF_EPOCH16 (two 8-byte floats). CDF_EPOCH is milliseconds from 0AD (a leap year) in an undetermined coordinate system; and CDF_EPOCH16 is seconds from 0AD and picoseconds within that second. At present, the CDF library routines for converting between Epoch and YMD HMS is reversible in the sense that they will return the same HMS as was used on input, but don't allow entering an actual leap second. Simple subtraction of Epochs does not include leap seconds in between. Strictly speaking, CDF Epoch (as it stands) is time from 0AD with no leap seconds, but in practice time values are usually entered in UTC, whether they included leap seconds during the mission or not. Epoch assumes the Gregorian calendar leap year scheme into the past (even though they should probably be Julian days before 1582). Since Epoch conversion routines ignore leap seconds, a leap second and the first second of the next day are set to the same EPOCH value and converting back returns the first second of the next day. It also ignores the varying lengths of seconds in UTC from 1961 to 1972 (both UTC second longer than SI second and leaps added in sub-second units).

GPS, SOHO, THEMIS, C/NOFS and other missions don't add leap seconds, while WMAP, Wind, Geotail, Polar, TRACE, RXTE do. To further complicate things, missions update their spacecraft clocks over a period of time around the leap seconds, as much as days off, and some slew the spacecraft clock over time and some increment at once but not always on time. Missions carry time in CDFs in EPOCH/EPOCH16, ASCII variables as strings, ISTP-like PB5 values, or in double-precision variables for seconds since some base time (such as THEMIS Unix time). These various schemes greatly hinder cross-comparison of data with other missions and hinder use by general data analysis tools (CDAWeb, Autoplot, etc.), requiring custom software development and attendant errors.

CDF will add a new CDF data type, CDF_TIME_TT2000, defined as an 8-byte signed integer with a fixed Time_Base=J2000 (Julian date 2451545.0 TT or 2000 January 1, 12h TT), Resolution=nanoseconds, Time_Scale=Terrestrial Time (TT), Units=nanoseconds, Reference_Position=rotating Earth Geoid. Given a current list of leap seconds, conversion between TT and UTC is straightforward (TT = TAI + 32.184s; TT = UTC + deltaAT + 32.184s, where deltaAT is the sum of the leap seconds since 1960; for example, for 2009, deltaAT = 34s). Accurate conversions from other time scales may require that data providers use the JPL NAIF SPICE or similar library, but data users will easily be able to convert to UTC time. Use of an 8-byte integer provides time with nanosecond resolution for the next 280 years, so data providers will no longer need 16-byte CDF_EPOCH16 variables to carry their highest time resolution (and in half the storage space). Pad values of -9223372036854775808 (0x8000000000000000) which corresponds to 1707-09-22T12:13:15.145224192; recommended FILLVAL is same.

CDF_EPOCH/CDF_EPOCH16 and their conversion routines will continue to be supported (including for times outside the range of CDF_TIME_TT2000) and will have variable attributes for defining the Time_Scale, Reference_Position, Resolution, and Leap_Seconds_Included (as well as Epoch's fixed Time_Base=0AD and Units=milliseconds). These attributes may also be applied to other time variables such as THEMIS times and for returning to mission times (which may lack some leap seconds).

CDF version 3.3.2 will include the basic support and routines for CDF_TIME_TT2000 and CDF_INT8 variable types, for testing and feedback; expected in mid 2011.

CDF version 3.4 will have full support for the CDF_TIME_TT2000 and CDF_INT8 variable types; expected late 2011 or early 2012.

More information on CDF_TIME_TT2000 and time schemes in general is available in Requirements for handling leap seconds in CDF.