Guy Harris wrote:
The UN*Xy file formats we read (libpcap, iptrace, some others) tend to
time stamp each packet with a UTC-based time.
Non-UN*Xy binary formats tend to store a capture start time, often
represented as year/month/day/hour/minute/second in local time, and store
an offset from that time as the time stamp.
Text-based capture formats tend either to have
year/month/day/hour/minute/second in local time, or just
hour/minute/second with no date stamp.
To handle *that* in its full generality is tricky. *Relative* times and
*delta* times are straightforward in all cases, but *absolute* times are
harder.
Converting UTC-based times to local time *in the time zone in which the
application is being run* is relatively straightforward - localtime(),
etc. can handle that. Converting it it *in the time zone in which the
capture was done*, if the capture was done in a different time zone - note
that "time zone" here refers not only to a region with a particular offset
from UTC, but also to the daylight savings time/summer time rules - is
harder.
Yes, see: http://www.ethereal.com/docs/eug_html_chunked/ChAdvTimezones.html
For one thing, you have to find out what that zone is, and
somehow be able to configure localtime() to use those rules, or to
otherwise be able to use them. On many UN*Xes you could, in theory, do
that by setting the TZ environment value appropriately, but the
appropriate value isn't the same on all UN*Xes (even those using the
"Arthur Olson" code - Solaris might still use the old-style TZ names, e.g.
"US/Pacific" rather than "America/Los_Angeles").
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?!?
But what's that difficult, once you have this offset?
We currently get the packet time stamps in UTC somehow and using
localtime() to convert them into "human readable" format AFAIK.
*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.
Obviously, the offset must be coming from the capture file or a user
preference setting (or such), otherwise Ethereal can't guess how to
display this in captured time if no such information is available ...
Or do I miss something out?
Regards, ULFL
