---- On Sun, 05 Aug 2018 14:12:31 +0100 Francois-Xavier Le Bail
<devel.fx.leb...@orange.fr> wrote ----
> On 05/08/2018 14:46, Denis Ovsienko wrote:
> > ---- On Sat, 04 Aug 2018 08:41:10 +0100 Francois-Xavier Le Bail
> > <devel.fx.leb...@orange.fr> wrote ----
> > > On 04/08/2018 09:03, Guy Harris wrote:
> > > > On Aug 3, 2018, at 6:44 PM, Michael Richardson <m...@sandelman.ca>
> > wrote:
> > > >
> > > >> Guy Harris <ghar...@sonic.net> wrote:
> > > >>> Currently, the tcpdump tests for AFS fail if you're not in the time
> > > >>> zone where the .out files were generated, because AFS time stamps
> > are
> > > >>> printed as local time rather than as UTC.
> > > >>
> > > >> That's broken
> > >
> > > Why broken ? it's just local time.
> >
> > The problem is to make the printed value unambiguous (i.e. for any valid
> > binary value VP1 from the packet there is exactly one printed string value
> > VS, and VS can be parsed into exactly one binary value VP2, and VP1 ==
> > VP2). If the VS value uses local clock time, the format should tell the
> > timezone, such that the output of tcpdump made in one time zone can be
> > correctly understood by the user in another (less human errors).
> >
> > One problem with setting TZ before running is that tcpdump output does not
> > tell what timezone it uses, and even if it does, some users will get
> > different output for the same input by default. Another is that the test
> > will require a custom script because at the moment the tests in TESTLIST
> > either all use a custom TZ, or none of them (as it is now).
> >
> > That said, if the output uses UTC, it could be helpful to use an
> > unambiguous format as well, as in commit 99412d6.
> >
> > > > So we should just change it to use gmtime() rather than localtime().
> > >
> > > I think an user prefer have the local time.
>
> There are two cases:
>
> 1) As a user, when I run a capture, I prefer the printing of local time for
> all time display.
> If, for any reason, I want to change this I can use: (TZ=... ; tcpdump ...)
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.
> 2) For tests in TESTLIST, we could build and check the output with TZ=GMT0
> (in TESTrun.sh and
> update-test.sh).
> Like that, we could run the tests without the '-t' option and get
> problems/changes in time printing
> functions. Need an update to the current tests outputs (I can do it).
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. I can make
the AFS test a custom test run with a nailed-down timezone if that makes
everybody happy.
--
Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
