On Tue, Jun 17, 2003 at 09:00:15PM +0100, Jon Fairbairn wrote:

On 2003-06-17 at 13:53BST "Simon Marlow" wrote:

...

-- * ClockTime

-- | A representation of absolute time data ClockTime = ClockTime { ctSeconds :: Integer, ctPicoseconds :: Integer }

Two Integer fields seems strange. Either ClockTime { ctPicoseconds :: Integer }

I strongly strongly agree with this. anything other than a single Integer seems silly since we have arbitrary precision integers, we might as well use them.

would seem to make more sense. I don't see that saving a divide by 10^12 is a big win. But being able to represent times shorter than a picosecond would be.

or ClockTime { ctSeconds :: Integer, ctPicoseconds:: real } or, better ClockTime { ctSeconds :: Ratio Integer }

I would prefer not to complicate the Time type like this at the moment, an ArbitraryTime or FracDuration type thing could be a seperate library. Mainly I just want to fix the fact that the current time library is completly unusable before worrying about extensions.

...

deriving (Eq, Ord, Show, Read)

-- | An empty 'TimeDiff' noTimeDiff :: TimeDiff

TimeDiff might as well just be an Integer, same argument as for ClockTime.

...

-- | Returns the difference between two 'ClockTime's

...

-- * CalendarTime

data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer, ctTZ :: Timezone }

again query Integer for picoseconds -- some sort of fractional value would be better.

...

-- | Convert a 'CalendarTime' to a 'ClockTime' -- TODO: can this raise an exception if the CalendarTime does not -- represent a valid time? Or should it return Maybe ClockTime? calendarTimeToClockTime :: CalendarTime -> ClockTime

I'd vote for Maybe since it's more "functional" than exceptions.

me too. as for the leap second issue, I suggest a simple solution inspired by http://freebsd.ntu.edu.tw/djb/proto/utctai.html ClockTimes and TimeDiffs are ALWAYS TAI with an epoch of 1970-01-01 00:00:10 TAI (to correspond to other libraries). a second is always a second. this greatly simplified the internals as simple arithmetic on integers is always correct. the only time UTC and leap seconds should come into play is when converting to or from a CalanderTime since UTC is meant to be a human-consumable notion of time, not a precise one. We will have to assume that an oracle exists to tell us which years had leap seconds in them, but such information is required by any scheme which works with UTC, many systems provide them and it is easy enough to embed a table. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------

John Meacham wrote:

...

ClockTimes and TimeDiffs are ALWAYS TAI with an epoch of 1970-01-01 00:00:10 TAI (to correspond to other libraries). a second is always a second.

The UTC second and the TAI second are precisely the same interval, and "tick" at the same time; TAI and UTC always differ by an integral number of seconds. TAI and UT0/UT1/UT2 are different. yeah, this is what I meant by the difference is only made when

On Tue, Jun 17, 2003 at 06:20:32PM -0400, Matthew Donadio wrote: translating to a calendarTime. when represented as an offset from a specific epoch, they SHOULD be the same. (but arn't in practice) when systems which work via an offset from epoch system work with UTC (even if the internal representation doesn't use offset from epoch, the same problems apply to any system which wishes to find the differences between times) time ONE of the following MUST be true: 1) a UTC second is interpreted as a generally unpredictable different duration than a TAI second. 2) past timestamps (and possibly current) are incorrectly interpreted by a generally unpredictable amount. 3) you have a table of every leap second and all is well. unixs tend to do 1 when synchronized externally (like via ntp). free-running boxen (without external synchronization) do 2. there are libraries which do 3 which is good.

...

this greatly simplified the internals as simple arithmetic on integers is always correct. the only time UTC and leap seconds should come into play is when converting to or from a CalanderTime since UTC is meant to be a human-consumable notion of time, not a precise one.

I'm not sure if this is really a correct notion of UTC.

TAI is atomic time, and ticks at a precisely defined rate. UT1 is corrected solar time (actually sidereal time converted to solar time and corrected), and due to quirks in the earth's rotation, is not constant. UTC is a comprimise between the two. UTC ticks at TAI's rate, but is corrected with leap seconds to it within +- 0.9 seconds of UT1.

simple arithmetic only works when option 1 above isn't chosen. however most people that say 'just use UTC and forget about leap seconds' are implicity choosing option 1 above without realizing it.

...

We will have to assume that an oracle exists to tell us which years had leap seconds in them, but such information is required by any scheme which works with UTC, many systems provide them and it is easy enough to embed a table.

I have to dig out my files on this (they are currently MIA due to job changes), but I believe the problem with this approach has to do with updating the leap second table in deployed systems. Also, all time broadcasts are by international agreement UTC (GPS may be different, but I can't remember), so anything a computer receives is going to be UTC. TAI may be the best thing to do in an ideal world, but the world is pretty much stuck with UTC.

* But you need those tables anyway. * There is no correct solution which involves UTC and does not require tables of leap seconds. But I recognize that such tables will not always be available or up to date, in which case the time might be a little off, but there is no way around that, such systems are just slightly non-conformant which is okay for many people, but we should not standardize on a vaugely defined incorrect semantics, rather we should choose the correct solution and let implementations do their best to conform to it on a given system. for an example why you can't do UTC without a table: convert 1000 seconds after epoch into a UTC CalendarTime. you can't without knowing how many leap seconds occured in those 1000 seconds. alternativly, assume you have UTC time nativly, convert 2000 seconds ago into a CalanderTime, you cannot without leap second tables because you don't know how many leap seconds occured in the last 2000. UNIX hacks around this by changing the length of a second around a leap second, so every timestamp when interpreted as an offset from epoch without any leap seconds (i.e. every minute is 60 seconds) is correct, but the tradeoff is that the length of a second is no longer defined and you can't do time arithmetic or time offsets correctly. the moral, saying use UTC doesn't mean anything precise unless you specify the hacky way to interpret UTC which is going to be just as complicated and less functional as saying use TAI in the first place. at least now we would have the ability to actually represent precise times when the system provides enough resources to do so. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------

On Tue, Jun 17, 2003 at 08:58:54PM -0400, Matthew Donadio wrote:

John Meacham wrote:

...

UNIX hacks around this by changing the length of a second around a leap second, so every timestamp when interpreted as an offset from epoch without any leap seconds (i.e. every minute is 60 seconds) is correct, but the tradeoff is that the length of a second is no longer defined and you can't do time arithmetic or time offsets correctly.

Are current libraries really this brain dead? I haven't dealt with time in almost 10 years, and always had very strict requirements (timetaging satellite telemetry). Sloppiness like that really surprises me.

yup. unfortunatly this brokenness is mandated by POSIX: POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of seconds between a specified time and the Epoch, according to a formula for conversion from UTC equivalent to conversion on the na basis that leap seconds are ignored and all years divisible by 4 are leap years. This value is not the same as the actual number of seconds between the time and the Epoch, because of leap seconds and because clocks are not required to be synchronised to a standard reference. The intention is that the interpretation of seconds since the Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further rationale. the only way to reconcile the POSIX time with real time is by changing the speed of the clock and hence the length of a POSIX second. even worse, POSIX got the formula for leap years wrong so you have to make up for a whole day at times (!!) (if you follow the standard exactly, the leap year problem is considered a typo by many). in any case, anyone who wants accurate times uses an alternate library such as djb's libtai or rolls their own solution. Using TAI internally and only dealing with UTC when translating between CalendarTimes has a number of advantages, CalendarTime already has a timezone field, so it is not even that odd to expect it to translate the time to UTC if that "timezone" is specified. TAI is well defined for arbitrary times in the past, using an 'Integer' means we can represent times accuratly across all of history and the future. :) This makes the native Time type in haskell suitable for actual scientific work, which is good. the only source of confusion I can think of is if the Integer representing TAI relative to epoch is misinterpreted as a time_t equivalent under POSIX, providing toPosixUTC :: ClockTime -> Integer and fromPosixUTC :: Integer -> ClockTime would be useful and advisable John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------

Oops, forgot to attach the code. ---------------------------------------------------------------------------- -- * ClockTime -- | A representation of absolute time, measured as picoseconds since -- the epoch, where the epoch is 1 January 1970 00:10 TAI. newtype ClockTime = ClockTime { ctPicoseconds :: Integer } deriving (Eq, Ord, Num, Enum, Integral, Show, Read) -- | returns the current absolute time getClockTime :: IO ClockTime -- | Difference between two 'ClockTime's newtype TimeDiff = TimeDiff { tdPicoseconds :: Integer } deriving (Eq, Ord, Num, Enum, Integral, Show, Read) -- | An empty 'TimeDiff' noTimeDiff :: TimeDiff -- | Returns the difference between two 'ClockTime's diffClockTimes :: ClockTime -> ClockTime -> TimeDiff -- | Adds a 'TimeDiff' to a 'ClockTime' addToClockTime :: ClockTime -> TimeDiff -> ClockTime {- Rationale: - POSIX's time_t uses a broken notion of "seconds since the epoch", defined by a formula in terms of UTC time ignoring leap seconds. Our ClockTime is defined so as to avoid this brokenness, but it means that a ClockTime cannot trivially be converted to a POSIX time_t. - TimeDiff is now an absolute measure of time period, as compared to the Haskell 98 TimeDiff which was underspecified in this respect. Invariants: t1 `addToClockTime` (t2 `diffClockTimes` t1) == t2 t1 `addToClockTime` noTimeDiff == t1 t1 `diffClockTimes` t1 == noTimeDiff -} ---------------------------------------------------------------------------- -- * CalendarTime data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer, ctTZ :: Timezone } deriving (Eq, Ord, Read, Show) data Timezone -- abstract -- | Make a 'Timezone' -- TODO: do we need to specify daylight savings time too? timezoneFromOffset :: Int -> Timezone timezoneFromName :: String -> Timezone timezoneOffset :: Timezone -> Int timezoneName :: Timezone -> String -- | Convert a 'ClockTime' to a 'CalendarTime' in the current timezone clockTimeToCalendarTime :: ClockTime -> IO CalendarTime -- | Convert a 'ClockTime' to a 'CalendarTime' in UTC clockTimeToUTCTime :: ClockTime -> CalendarTime -- | Convert a 'CalendarTime' to a 'ClockTime'. Some values of -- 'CalendarTime' do not represent a valid 'ClockTime', hence this -- function returns a 'Maybe' type. calendarTimeToClockTime :: CalendarTime -> Maybe ClockTime {- OPTIONAL: these are hard to implement, and require careful specification (see rationale below): addPicoseconds :: CalendarTime -> Integer -> CalendarTime addSeconds :: CalendarTime -> Integer -> CalendarTime addMinutes :: CalendarTime -> Integer -> CalendarTime addDays :: CalendarTime -> Integer -> CalendarTime addWeeks :: CalendarTime -> Integer -> CalendarTime addMonths :: CalendarTime -> Integer -> CalendarTime addYears :: CalendarTime -> Integer -> CalendarTime Rationale: - Adding "irregular" time differences should be done on CalendarTimes, because these operations depend on the timezone. - Need to define the meaning when the offset doesn't exist. eg. adding a day at the end of the month clearly rolls over into the next month. But what about adding a month to January 31st? -}

On 2003-06-18 at 19:17+0200 Dylan Thurston wrote:

On Wed, Jun 18, 2003 at 11:22:55AM +0100, Simon Marlow wrote:

...

-- | Convert a 'ClockTime' to a 'CalendarTime' in the current timezone clockTimeToCalendarTime :: ClockTime -> IO CalendarTime =20 -- | Convert a 'ClockTime' to a 'CalendarTime' in UTC clockTimeToUTCTime :: ClockTime -> CalendarTime

clockTimeToUTCTime also needs to return IO CalendarTime, since it will certainly need to look up a table of leap seconds.

Looking things up in tables isn't IO per se. Are you saying that the table changes sufficiently often that it can't be regarded as constant, and that as a consequence clockTimeToUTCTime c doesn't always have the same value? Now, I know from the earlier discussion that for far future dates the leap seconds will be unknown, but isn't this a case of going from _|_ to a value, rather than a change of (non-_|_) value? While I can live with the idea that a programme may be undefined if it computes dates far enough in the future, I'd be unhappy if running it one day gives one answer and on another gives something else. This particular can seems to contain the "need for a number representation that can be inspected lazily to a certain precision" worm. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

John Meacham wrote:

I thought about this too, in my opinion converting to a CalendarTime is 'logically' functional in that the only reason the conversion would ever vary is with incomplete information and an approximation in the first place. if we consider the table of leap seconds to be an 'oracle' which is complete (which is the useful approximation to reality most applications can assume) then it IS a purely functional operation.

I thought about this last night too, and I also agree. As long as everyone's installations are fully up-to-date, it is a function. When defining behaviour, we don't take into account broken compilers, so we shouldn't have to take into account broken/out-of-date installations, either. This does get a bit less clear when future dates are considered, but I still think making it IO is overkill. There is after all just one table (somewhere out there in Plato's universe...), it's just that we don't know what's in it. We could say "the behaviour of this function is undefined for future dates" or some such. --KW 8-)

New version of the System.Time proposal attached below. I've incorporated most of the comments so far. Changes relative to the last version: - ClockTime is now abstract - TimeDiff and associated operations have gone altogether, since ClockTime is an instance of Num they aren't necessary. This is perhaps controversial, since there is less type safety now (you can mix time differences with absolute times), but the alternative is to remove the Num instance from ClockTime. - Timezone offsets are in minutes (apparently this is necessary - if someone could provide a reference I'd be grateful). It's just occurred to me that since TAI is a valid timezone name, it isn't always sensible to ask what the "timezone offset" is. - added getCurrentTimezone - added clockTimeToCalendarTimeTZ - added notes to clockTimeToCalendarTime about possible problems with times in the future. - added notes about possible normalizeCalendarTime operation. Thanks for all the input so far, I think we might be converging! Cheers, Simon -- ------------------------------------------------------------------------- -- * ClockTime -- | A representation of absolute time, measured as picoseconds since -- the epoch, where the epoch is 1 January 1970 00:10 TAI. data ClockTime -- abstract instance of (Eq, Ord, Num, Enum, Integral, Show, Read) -- | returns the current absolute time getClockTime :: IO ClockTime {- Rationale: - POSIX's time_t uses a broken notion of "seconds since the epoch", defined by a formula in terms of UTC time ignoring leap seconds. Our ClockTime is defined so as to avoid this brokenness, but it means that a ClockTime cannot trivially be converted to UTC based times such as the POSIX time_t. -} -- ------------------------------------------------------------------------- -- * Timezone data Timezone -- abstract -- | Make a 'Timezone' from an offset, in minutes relative to UTC, -- which must be less than @24*60@. timezoneFromOffset :: Int -> Timezone -- | Make a 'Timezone' from a standard timezone name (eg. GMT, PDT). -- TAI is a valid timezone name. timezoneFromName :: String -> Timezone -- | Return the offset in minutes of the specified timezone relative -- to UTC. timezoneOffset :: Timezone -> Int -- | Return the timezone name corresponding to a 'Timezone' value. timezoneName :: Timezone -> String -- | Returns the current timezone from the environment. On Unix, the -- current timezone is taken from the @TZ@ environment variable, or -- the system default if @TZ@ is not set. getCurrentTimezone :: IO Timezone ----------------------------------------------------------------------------- -- * CalendarTime data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer, ctTZ :: Timezone } deriving (Eq, Ord, Read, Show) -- | Converts a 'ClockTime' to a 'CalendarTime' in UTC. -- -- Note that this function may produce unpredictable results for -- times sufficiently far in the future, because it is not known -- when leap seconds will need to be added to or subtracted from -- UTC. Note that this doesn't apply if the timezone is TAI. -- clockTimeToUTCTime :: ClockTime -> CalendarTime -- | Converts a 'ClockTime' to a 'CalendarTime' in the current timezone. -- Caveats for 'clockTimeToUTCTime' also apply here. clockTimeToCalendarTime :: ClockTime -> IO CalendarTime -- | Converts a 'ClockTime' to a 'CalendarTime' in the specified timezone. -- Caveats for 'clockTimeToUTCTime' also apply here. clockTimeToCalendarTimeTZ :: Timezone -> ClockTime -> CalendarTime -- | Convert a 'CalendarTime' to a 'ClockTime'. Some values of -- 'CalendarTime' do not represent a valid 'ClockTime', hence this -- function returns a 'Maybe' type. calendarTimeToClockTime :: CalendarTime -> Maybe ClockTime {- OPTIONAL: these are hard to implement, and require careful specification (see rationale below): addPicoseconds :: CalendarTime -> Integer -> CalendarTime addSeconds :: CalendarTime -> Integer -> CalendarTime addMinutes :: CalendarTime -> Integer -> CalendarTime addDays :: CalendarTime -> Integer -> CalendarTime addWeeks :: CalendarTime -> Integer -> CalendarTime addMonths :: CalendarTime -> Integer -> CalendarTime addYears :: CalendarTime -> Integer -> CalendarTime Rationale: - Adding "irregular" time differences should be done on CalendarTimes, because these operations depend on the timezone. - Need to define the meaning when the offset doesn't exist. eg. adding a day at the end of the month clearly rolls over into the next month. But what about adding a month to January 31st? OR: we could provide normalizeCalendarTime :: CalendarTime -> CalendarTime where the following invariant holds: forall t . isJust (calendarTimeToClockTime (normalizeCalendarTime t)) that is, normalizeCalendarTime turns a possibly invalid CalendarTime into a valid one. The intention is that addDays could be implemented as: addDays t days = normalizeCalendarTime t{ ctDays = ctDays t + days } We still need to specify what exactly normalizeCalendarTime does, however. Presumably it needs to know about leap seconds, for example. -}

On 2003-06-20 at 17:14BST Keith Wansbrough wrote:

...

- Timezone offsets are in minutes (apparently this is necessary - if someone could provide a reference I'd be grateful).

Australia.

Or, more excitingly, Nepal: tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent or ocean. [...] 5) Asia [...] #? 5 Please select a country. [...] #? 32 The following information has been given: Nepal Therefore TZ='Asia/Katmandu' will be used. Local time is now: Fri Jun 20 22:35:04 NPT 2003. Universal Time is now: Fri Jun 20 16:50:04 UTC 2003. Is the above information OK? -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

On Fri, Jun 20, 2003 at 03:20:39PM +0100, Simon Marlow wrote:

- Timezone offsets are in minutes (apparently this is necessary - if someone could provide a reference I'd be grateful). It's just occurred to me that since TAI is a valid timezone name, it isn't always sensible to ask what the "timezone offset" is.

http://www.timeanddate.com/time/abbreviations.html lists several timezones with half-hour offsets (e.g., Newfoundland). Should there also be a function to get offsets (in seconds) between UTC and TAI? Peace, Dylan

On Fri, Jun 20, 2003 at 01:45:03PM -0700, John Meacham wrote:

On Fri, Jun 20, 2003 at 07:36:23PM +0200, Dylan Thurston wrote:

...

Should there also be a function to get offsets (in seconds) between UTC and TAI?

On reflection, I think this is too precise information to be accessible from a portable library. In particular, I'm not sure it's possible to correctly implement a TAI-based time system on most Linux distributions without modification (I was rather shocked to discover this...), and I'm sure there are some desired platforms for Haskell which make it very hard to implement that. So the standard should _allow_ for correct implementations, but not _require_ it.

yes. this would solve another problem I mentioned in a different email about the user implementing their own time types and needing the raw leap second info. perhaps:

leapSeconds :: ClockTime -> Int ...

That's probably too precise: perhaps the implementation has no access to raw leap seconds, or perhaps the standard changes and the offset is no longer an integer number of seconds. Peace, Dylan

"Simon Marlow" writes:

- ClockTime and TimeDiff are now represented as Integer picoseconds only. Hence, they also now derive Num, Enum, and Integral.

I think this is the most aesthetically pleasing. From a practical point of view, we should perhaps consider the possible need to represent times of higher resolution, and the practical need to use of much lower resolution. Division by 10^12, or the need to push really large integers around isn't going to end up being costly, is it?

- ClockTime is defined as picoseconds since the epoch, where the epoch is defined in terms of TAI.

- calendarTimeToClockTime now returns a Maybe.

Okay, this is perhaps more "functional", but is it really what I want? Wouldn't an illegal calendarTime often be a bug in the code, and if so, isn't it better to just crash? I don't much care for wrapping things in Maybe, could we have an 'isCalendarTimeValid' instead (in order to verify values that aren't static)? I.e., isn't this foo ct | isCalendarTimeValid ct -> ...calendarTimeToClockTime ct... | otherwise -> error ... as useful as this foo ct = case calendarTimeToClockTime ct of Just t -> .... Nothing -> error ... ? And of course cleaner in the cases where you *don't* need to check?

- I've commented out addDays and friends. I assume that there isn't an immediate demand for these functions, so they can be left out until later, or moved to a separate library.

-kzm -- If I haven't seen further, it is by standing in the footprints of giants

"Ketil Z. Malde" wrote:

"Simon Marlow" writes:

...

- ClockTime and TimeDiff are now represented as Integer picoseconds only. Hence, they also now derive Num, Enum, and Integral.

I think this is the most aesthetically pleasing. From a practical point of view, we should perhaps consider the possible need to represent times of higher resolution, and the practical need to use of much lower resolution. Division by 10^12, or the need to push really large integers around isn't going to end up being costly, is it?

Representing times as `Rational` seems more elegant: * It handles widely varying needs for resolution nicely. * It avoids choosing picoseconds as the finest possible resolution. What are the downsides to `Rational`? And if those downsides are serious enough, it would seem that the next best approach would be to represent times abstractly. Dean

Graham Klyne writes:

On any hardware than I'm familiar with, processing rationals, or unlimited precision numbers, is significantly more expensive than using the native machine capabilities.

This was, sort of, a concern I tried to raise: using Integer with ps, makes for some large quite numbers (and Integer is of course slower with large numbers than with small ones)

If the view is that Haskell is primarily for writing programs that are provably correct in all conceivable circumstances, then the case for using rational time values is clear.

I don't think we should sacrifice correctness, it is a far greater problem for much more code, than speed is.

My point is that seconds and picoseconds, represented using 64 bit binary values,

Well, my main problem with representing time as a pair, is that a point in time isn't uniquely defined (e.g. should it be 3s + 5e-11ps, or 2s + 5e-11ps), and that, in most suggested formats, they overlap (e.g. 3s or 2s + 1e12 ps). So you need to normalize -- possibly after each operation. Are you sure this is more efficient than using bignums? Further, I'm not sure Haskell has a standard 64 bit Int. I'm fairly sure it's in GHC, and probably in the other compilers, but it'd be nice if it were in the standard. On the other hand, Integer can be implemented any way that's efficient on each architecture.

I find it hard to lose sleep over missing leap-seconds and dates beyond

Leap seconds are a completely orthogonal issue. From the discussion here, it seems plain that UTC is a kluge, and TAI is the way to go. In any case, we already agree to counting seconds, the question is how to count them :-)

And the cost of supporting all this may be trivial in practical terms -- I don't have a good handle on that, but I'll comment that time calculations might be a significant computational burden for a real-time system dealing with high event rates (and I think we'll see lots of these applications).

Could you be more concrete? I don't think I know any system that spends a significant amount of time calculating dates. Some systems that deal with time (GPS, NTP), mostly care about differences, and are happy to have the clock roll over relatively frequently. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Simon Marlow wrote:

John suggested using (pico)seconds since 1970-01-01 00:00:10 TAI. Isn't this equivalent to saying that ClockTime is the number of seconds since 1970-01-01 00:00:00 UTC?

Yes. TAI started ticking on 1 Jan 1958. UTC started ticking on 1 Jan 1972, and started 10 seconds behind of TAI (to keep it within 0.9 sec of UT1). -- Matthew Donadio (m.p.donadio@ieee.org)