> -----Original Message-----
> From: Andreas Siegert [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, October 21, 1999 5:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: timestamps and timezones (was: time-sync)
>
> Quoting Chris Calabrese ([EMAIL PROTECTED]) on Thu, Oct 21,
> 1999 a
> t 11:05:48AM -0400:
> > seconds-since-the-epoch-in-ascii.fraction
> >
> > * Resolution - variable
> > * Bandwidth - under 12 bytes (including stop byte) to do second
> resolution
> in
> > the foreseeable future, more to do higher resolution
>
> We definitely do not want to create a protocoll now that will die
> horribily in
> 2038, so it is getting a bit huge.
>
Huh? 11 digits worth of seconds takes you out to 5138, and there's nothing
here that limits the number of digits (I was just pointing out that you'll
use less than 11 digits for the foreseeable future - in fact 10 digits gets
you to 2286). Yes, you'll need a 64-bit machine/OS to do the conversion
easily starting in 2038, but that's certainly better than creating a
protocol that requires a 64-bit machine today.
> > * Ease of processing off the wire - no processing needed
> If you use DB facilities, they will work better on real dates than on
> thsis
> UNIXism.
>
Yeah, I'm willing to concede the point. I'm beginning to think
YYMMDDmmhhss.fraction really is better since it's easier to deal with in a
tcpdump, etc.
