Ethereal-dev: Re: [Ethereal-dev] [Proposed Patch] netxray.c: display frame time reflecting TZ
Ulf Lamping wrote:
> I was thinking about this, but as far as I remember someone (Guy?)
> mentioned that practically every sniffer uses UTC to store the time stamps.
Given that I've dealt with several sniffer formats that don't, I'm not
sure I would have said that. :-)
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. 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.
And, of course, there's then the issue of times in packets themselves,
which could either be UTC-based or local....
