Re: Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?

[Denis Ovsienko <denis () ovsienko info>]

 ---- On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson <jhawk () MIT EDU> wrote ---- 
> Denis Ovsienko <denis () ovsienko info> wrote on Sun,  5 Aug 2018 
> at 17:05:20 +0100 in <1650ad5fd29.b5d2798f311917.536858429581803402 () ovsienko info>: 
>  
> > It works in an interactive session; but as soon as the output makes 
> > it to the Internet and stays there long enough, people will no 
> > longer understand what the printed time was in their local time or 
> > UTC. The value of TZ influences the output, but remains invisible. 
>  
> I think this is not a real problem; in practice it's rare that long-lived non-.pcap tcpdump decodings have 
> significant meaning associates with the time zone of time outputs from printers. One could imagine printing the 
> local time zone adjacent to the "listening on" output at startup, but it seems unnecessary. 
>  
> But it's important not to let theoretical issues make the tool worse for actual users. 

Thank you for your input John.

When a network protocol has a timestamp and defines it in UTC (which is often the case), to me it looks consistent if 
the host in the middle of the exchange (or completely out of the exchange, if that is a .pcap file) prints it in UTC as 
well. Such as, for example somebody in time zone A decoding NTP packets between hosts in time zones B and C --- why 
would the man in the middle need to translate the timestamps to any of those timezones when NTP encodes and operates 
UTC in the first place?

The protocol terminating software would be more likely to need to translate UTC to a local timezone to verify or action 
it. Opposed to that, a protocol decoder just tells you what's on the wire.

I accept my point of view may make less sense to other people.

> > I understand what you are suggesting, and your description is 
> > correct, but it does not solve the problem of interpreting tcpdump 
> > output correctly in a place or time different from the 
> > original. That said, I can live with print-rx.c using local time and 
> > being imperfect, it has worked like this many years. Still, I think 
> > local time should not be the norm for other decoders. 
>  
> Doesn't this argument apply for other decoders as well? Whatever is done should not make the output of decoders 
> harder for the diagnostic users of tcpdump to interpret, or unnecessarily change the output format. 

The factor of consistency does indeed apply, and some decoders use UTC already, whilst some others seem to use local 
time and to fail the tests from time to time. Which reminds us that at the end of the day somebody will need to fix the 
AFS test, whatever is the consensus.

> One could imagine having all of these printers respect -tt, &c., and conceivably adding an option to force decoder 
> time printing to be UTC; but such an option would be tantamount to setting TZ=UTC, and generally the Unix Way is not 
> to duplicate such OS functionality. 
>  
> p.s.: Using GMT or GMT0 is deprecated, please use UTC instead. 
>  
> --jhawk () mit edu 
>   John Hawkinson 
-- 
    Denis Ovsienko


_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers