[Feels like too implementationish at this point to discuss the format of the
timestamps when we still don't know exactly what we're trying to accomplish, but I
think this needs to be said...]
The logging system doesn't actually look at the timestamps until somebody/something
looks at the stored logs. Nothing ever looks at the timestamps on the wire.
Therefore, the only considerations for the timestamps on the wire are:
1. Resolution (seconds, milliseconds, etc.)
2. Bandwidth
3. Ease of processing off the wire
4. Ease of processing to make human readable
5. Ease of doing date arithmetic
A 64-bit binary microsecond counter comes out like this:
* Resolution - excellent
* Bandwidth - 8 bytes
* Ease of processing off the wire -poor on processors not capable of doing
64-bit processing, especially if different endianness than net transmission
* Ease of processing to get human readable - poor on processors not capable of
64-bit processing
* Ease of doing date arithmetic - poor on processor not capable of 64-bit
processing
YYYYMMDDHHMMSS.fraction
* Resolution - variable
* Bandwidth - 15 bytes (including stop byte) to do second resolution, more to do
higher resolution
* Ease of processing off the wire - no processing needed
* Ease of processing to get human readable - simple string manipulation to get
to something mktime() can deal with
* Ease of doing date arithmetic - easy after feeding to mktime()
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
* Ease of processing off the wire - no processing needed
* Ease of processing to get human readable - easily feed to gmtime()
* Ease of doing date arithmetic - easy after feeding to gmtime()
Sounds like this last one wins if you ask me.
Furthermore, timezones are just a bad idea altogether because:
1. Nobody really cares about what the timezone was on the original machine. They
only care about the timezone they're in when they're reading the logs.
2. Dealing with multiple machines having different timezeones but their logs
going to the same file is too much of a pain.
Just use UTC.
Klaus Moeller wrote:
> >
> > 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]
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
