On 2009-05-15 03:10, Guy Harris wrote: > On May 14, 2009, at 7:20 PM, Jefferson Ogata wrote: >> But the point of storing the mostly irrelevant zone data as metadata >> is so that it can be recorded when pcap timestamps are UTC, as they >> always should have been. I'd like to find the person who decided to >> store localtime instead of gmtime in the pcap timestamp field and >> smack him or her with a large sock filled with horse manure. > > What application or applications make that mistake?
>From the mere existence of this thread, I was assuming tcpdump does. :^) 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. 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. > However, even with standard pcap files, which have GMT time stamps, one > might want to be able to display the time stamps in the time zone in > which the capture was done rather than in the time zone in which it's > being read; that's what the original poster wanted. Storing time zone > information in the file, rather than getting it out of band (e.g., > asking whoever sent you the file where they captured it) isn't a > requirement, but it could be a convenience. Storing offset from UTC as metadata can work even across DST changes by dropping in a new offset metadata record when the zone change occurs. It doesn't have to be global. -- Jefferson Ogata <[email protected]> NOAA Computer Incident Response Team (N-CIRT) <[email protected]> "Never try to retrieve anything from a bear."--National Park Service - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
