On Mon, Apr 19, 2004 at 04:15:18PM +0200, Rolf Fiedler wrote:
> I mean it will always be tricky if you do not know the day the trace
> was generated, but the toshiba format is sub-optimal in this respect.
Yes.
> Also if the trace runs for more than a day it jumps back in time.
That's a bit tricky to handle.
One solution might be to have Wiretap supply, for each packet, *two*
values:
1) an absolute time stamp, containing an
hour/minute/second/fractional-second time and an *optional*
date as year/month/day;
2) a time stamp relative to the beginning of the capture - or,
for capture file formats that don't store a capture start
time, relative to the first packet's arrival - in seconds and
fractional seconds;
and have Ethereal display the first value as the date/time - and not
display the date if it's not available - and use the second value for
relative and delta times.
That would raise the question of what Wiretap should do when *writing* a
capture:
for output file formats whose packets have an absolute UTC-based
time stamp (e.g., libpcap), use the capture start time stamp
(which Wiretap could supply both as Y/M/D/H/M/S.F and a
UNIX-style time stamp) and the relative time stamps to compute
the absolute time stamps;
for output file formats that have a capture start time and whose
packets have a time stamp relative to that start time (e.g.,
Microsoft Network Monitor), use the capture start time stamp and
relative time stamps;
if the input file has only time stamps, not date-and-time
stamps, use the file's mod time as the starting time.
I *think* that covers all the file formats we currently write.