>
> 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.
>
> I'd be inclined to go with two Ms and use a numeric month. Not sure what
> we're going to do about the Y10K issue, though. Timezone should probably
> be available as an optional field in the message, but in its absence
> timestamps should be interpreted as if they were in UTC.
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).
Time zone can be supported by another 32 bit integer that gives an
offset in seconds from GMT (16 bits are not enough to cover 12 * 3600
seconds, not considering daylight savings time).
IMHO it is more important to have a format that can be processed
easily that read by humans. A log file viewer can always be used to
convert the binary field back to human readable date format.
Klaus
--
Klaus Moeller | mailto:[EMAIL PROTECTED]
DFN-CERT GmbH |
Vogt-Koelln-Str. 30 | Phone: +49(40)42883-2262
D-22527 Hamburg | FAX: +49(40)42883-2241
Germany | PGP-Key: finger [EMAIL PROTECTED]
