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: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html