Re: local timestamp recovery of .cap files

[Guy Harris <guy () alum mit edu>]

On May 15, 2009, at 12:43 AM, Jefferson Ogata wrote:

> This has come up before, back when we were talking about the NG  
> format.
> I guess I got confused by the current context; if pcap files are
> natively UTC (which I had thought they were until this thread arose,
> seeming to suggest they weren't), great.

They are.

The issue in the thread is how to *display* the time stamps,  
especially if you want to know what *local* time, at the point of  
capture, a packet arrived, when you're reading it in a different time  
zone.  *That* requires that some form of time zone information for the  
point of capture be available, whether in the capture file or, for  
example, in an email to which the capture file was attached.  So  
there's a use for time zone information in a capture file even when  
the time stamps in the capture file are in UTC.

> I configure all my systems in
> UTC anyway, so I never have issues, and I wouldn't be able to tell
> without tweaking $TZ.
>
> Frankly, I don't understand why anyone configures a UNIX-like system  
> in
> anything other than UTC. That's what $TZ is for.

There are two ways I see in which "configure a UNIX-like system for a  
particular time zone" could be read:

	1) set the default time zone used by routines such as localtime() and  
mktime() to convert UTC to local time;

	2) set the time zone of the value returned by time()/gettimeofday()/ 
etc..

2) makes no sense whatsoever, as time()/gettimeofday()/etc. are  
*defined* to return UTC-based values.

1) makes perfect sense, unless you want the date command, the time  
stamps in log files, whatever clock is displayed in the GUI, etc. to  
show UTC rather than local time.  Some people might want that, but  
that's not *ipso facto* what *everybody* should want.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.