[154487] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: F-ckin Leap Seconds, how do they work?

daemon@ATHENA.MIT.EDU (Peter Lothberg)
Thu Jul 5 11:37:26 2012

Date: Thu, 5 Jul 2012 17:34:18 CEST
From: Peter Lothberg <roll@Stupi.SE>
To: Jimmy Hess <mysidia@gmail.com>
In-Reply-To: <CAAAwwbV2D64jxQKsJu-Nw-zhi=53CakGzu_ys+dovz7-XvFa9g@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


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@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
> 
> 



home help back first fref pref prev next nref lref last post