F-ckin Leap Seconds, how do they work?

Peter Lothberg roll at Stupi.SE
Thu Jul 5 17:34:18 UTC 2012


Most systems that deals with time has a slightly different way of 
doing it than U*ix..  ref: CCIR 457-1

Like this:

56113.6294791667
56113.6301736111  

56113 is MJD, modified julian date (http://tycho.usno.navy.mil/mjd.html)

Want to knew the time between two observations, just subtract and you
get days and fraction of day. (I's about 60sec between the lines above..)


--P

Ps: Tops20/Twenex/Tenex keeps the kernel time this way, in 18+18 bits...

> On 7/3/12, Vadim Antonov <avg at kotovnik.com> wrote:
> > There's always a possibility of using pseudo-TAI internally by
> > reconstructing it from UTC. This is not the best solution (because it
> > requires systems to have long-term memory of past leap seconds, or
> How about, instead of requiring systems to "remember"  past leap seconds;
> 
> You represent every single timestamp  instead of as
> timestamp =  <32-bit int, seconds since jan 1 1970 00:00:00>
> 
> You represent all system timestamps as tuples:
> timestamp = (   <32-bint int seconds since jan 1 1970 00:00:00>,
>                           <integer representing the leap-second offset
> since jan 1 1970>  )
> 
> No need to retain a history.   Just retain the data in the same way
> that  Hours, Minutes, and Second are retained.
> Comparison is simple.
> 
>   (Timestamp2  - Offset2)  -  (Timestamp1 - Offset1)
> 
> 
> The downside is you can no longer set your system clock by hand,
> because humans won't know the right number of   "leap seconds"  to
> supply  when setting the time from their wall clock.
> 
> That's a problem necesitating you keep a history anyways.
> For time to be universally coordinated, it has to be coordinated.
> 
> One of the basic requirements for system time is that it interacts
> with humans, and
> humans have to be able to set their clock  from conventional time
> sources which are based on local time,   without the machine having to
> be constantly updated or reach out on a network and figure out how
> that translates into a reasonable machine time.
> 
> --
> -JH
> 
> 





More information about the NANOG mailing list