Ulf Lamping wrote:
Guy Harris wrote:
...
Similarly, handling a start time specified as
year/month/day/hour/minute/second, plus offsets, is tricky outside the
zone in which the capture was done, as you'd need the daylight savings
time/summer time rules for that zone.
As you mentioned above, some capture files use this "local time stamp"
format, so how is this handled today?!?
We treat the local time stamp as being a time stamp in the local time
zone, and convert it to UTC under that assumption, which means the time
stamps might be wrong if, for example, the time stamp was during
daylight savings time/summer time in the zone in which it was captured
but not in the zone in which it's being viewed.
> *If* we have the offset value between UTC and the captured time,
> we can
> simply add (delete) this value from the UTC value and *then* use
> gmtime(), which is an official ANSI-C function.
In NetXRay and Windows Sniffer files, and in some other formats
(libpcap, snoop, *Peek, etc.), the time stamps are absolute UTC values.
In that case, the offset between UTC and the captured time depends on
the daylight savings time/summer time rules.
Getting the offset between UTC and local time at the start of the
capture won't *always* let us display the local time, but the only time
when it won't would be if we have a capture that crosses a standard
time/{daylight savings,summer} time boundary.
Getting the standard-time offset between UTC and local time will work
only if the capture is taking place during standard time. Is the offset
in Windows Sniffer files the standard-time offset (e.g., -8 hours in the
US or Canadian Pacific time zone, regardless of whether daylight savings
time is in effect or not), or is it the *current* offset (e.g., -7 hours
in the US or Canadian Pacific time zone when daylight savings time is in
effect)?
In Network Monitor and DOS Sniffer files, the start time is a local
time, and packet time stamps are relative to that start time (Network
Monitor, DOS Sniffer).
To convert the start time to UTC, we'd need the current offset between
local time and UTC. To convert that to any form of local time, we'd
need the DST rules to get the right answer for all packets; we could get
the right answer for captures that don't cross standard time/{DST,
summer time} boundaries.
