superlifter design notes (was Re: Latest rZync release: 0.06)

[jw schultz]

On Fri, Jul 26, 2002 at 09:03:32AM -0400, Bennett Todd wrote:
> 2002-07-26-03:37:51 jw schultz:
> > All that matters is that we can represent the timestamps in
> > a way that allows consistent comparison, restoration and
> > transfer.
> 
> A very good statement indeed. There are complications, though. Some
> time representations used by computer systems have ambiguities, two
> different times that are represented with the same number, or two
> different representations (created at different times) that actually
> end up representing the same time.
> 
> > [...] we can pick as an epoch any time in recorded human history.
> > I don't feel qualified to impose any epoch myself.  I would be
> > inclined to stick with the UNIX epoch for the sake of convenience.
> 
> Which Unix epoch? 1970-01-01 00:00:00? 1970-01-01 00:00:10, and
> changing every time they issue a new leap second?

Hey, the whole leap second issue is a matter for the
libraries.  If the library is wrong then the system time
might be off by 10 seconds or so to compensate. we need not
care.

It doesn't matter as long as on the same platform it is the
same for converting back and forth.  We aren't determining
whether a file on one machine or filesystem is newer or
older than the coresponding file at the other end.  We are
determining that it is same or not (modulo precision).  Newer
or older are immaterial unless the system clocks are and
have always been in perfect sync.  Hey, some systems will be
running with a timezone offset of 0 and the clock set to
localtime.

> 
> > Conversion with any other time representation should be a matter
> > of t * scale + offset.
> 
> The trick is that offset. Given the different timekeeping systems
> in use, you can't correctly translate from one to another over
> a range of dates extending over years unless you either have a
> leap-second table of your own and convert to an absolute time
> format, or else you choose something like ISO 8601, and use local
> routines on each platform to convert to and from YYYY-MM-DD
> HH:MM:SS in UTC, recognizing that SS can exceed 59 when there are
> leap-seconds, and that sometimes, converting back to a machine's
> internal representation, you may have to fudge for that if the local
> conversion routines don't know about leap seconds.

We only need to deal with YMD... time if that is what the
system uses.  POSIX platforms do not.  We are talking about
converion and comparison between binary values where
leap-seconds don't matter.

> 
> TAI has the advantage that while various platforms have troubles
> getting to and from it, those have often been solved by other people
> (djb for Unix systems), and once you get to TAI you know where
> you're at:-).

I don't wish to disparage TAI but i've yet to see any
pragmatic reason why we should use it in this context.  If
you are aware of one please tell us.  Forget the
advertising, tell us about technical details TAI and why for
the purposes of file tree syncronization TAI is preferable
to something more closely related to the most-common native
form.  I have better things to do that spelunk some obscure
library implementing a time format not native to any
platform.  What is the actual format of TAI?  The docs you
point to talk of a structure and and two packed formats but
do not define these. TAI may be wonderful but not suitable
for this purpose.





-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt