Quoting Klaus Moeller ([EMAIL PROTECTED]) on Thu, Oct 21, 1999 at 12:06:51PM +0200:
> >
> > At 12:58 PM 10/20/1999 +0200, Andreas Siegert wrote:
> > >Quoting Kriss Andsten ([EMAIL PROTECTED]) on Wed, Oct 20, 1999 at
> > 12:14:11AM +0000:
> > >> > > Also the lack of timeZONE info in the timestamp is a common gripe. It
> > >> > > might be worthwhile to add a short field with this info i.e:
> > >> > > 991019_12:54:02_GMT+8.
> > >>
> > >> Question? What's wrong with sending in UTC, and munging into whatever on
> > >> the recieving end? (Anything that makes a payload going over the network
> > >> longer without a rather good reason is -evil-)
> > >
> > >YES!
> > >YYYYMMMDDhhmmss should be small enough, and even readable enough.
That should have been
YYYYMMDDhhmmss
sorry
> Why not go with a simple 64 bit counter with microsecond resolution ?
> That would give us support way into Y584K and is easy to process if
> transmitted in binary form. The performance would be much better, as
> the date could be processed directly, without the need to convert to
> and from strings. And conversion from existing UNIX time values is
> easy: Simply multiply by 1000,000
>
> This would even save some space (YYYYMMDDHHSS: 14 bytes).
This is ok for the transfer over the wire, if a human readable format is used
for storage. But I would prefer a readable format even on the wire. Makes for
easier diagnostic in tcpdump/tcpshow.
cheers
afx
--
SuSE Muenchen GmbH Phone: +49-89-42769-0
Stahlgruberring 28 Fax: +49-89-42017701
D-81829 Muenchen, Germany
May the Source be with you!
