On Dec 31, 2016, at 11:08 AM, Thomas Wiens <[email protected]> wrote:
> I was searching for the problem of displaying time zone names with
> german umlauts, and found that there is an exististing bug
> report (Bug 11785).
>
> I found that undefining HAVE_TZNAME so that the utf8 conversion in
> get_zonename (to_str.c) is called, fixes the problem.
>
> Is there any non-Windows environment where tzname (without underscore)
> is supposed to be available,
Yes. All Single UNIX Standard-compliant UNIXes have it:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/daylight.html
and so do some UNIX-like systems that don't claim SUS compliance but that are
intended to be UNIX-compatible:
http://man7.org/linux/man-pages/man3/tzname.3.html
In the SUS-compliant UNIXes systems, tzname[0] and tzname[1] will be short
abbreviations using only ASCII characters:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
("all characters ... shall be alphabetic characters from the portable character
set in the current locale" - see the definition of TZ), and in Linux, the same
will be true, because most if not all Linux distributions use the IANA time
zone database, where there's an explicit policy of conforming to the SUS in
that regard.
The BSDs and macOS support the tm_zone member of struct tm; those systems use
the IANA time zone database and the value of tm_zone follows the same rules as
the rules for the strings pointed to by the members of tzname.
So that covers all the UN*Xes out there; none of them have to worry about
converting the time zone abbreviation to UTF-8, because it's ASCII and thus
valid UTF-8.
> or is Wireshark supposed to be compiled
> with a MS Visual Studio version which does not have _tzname?
It's supposed to be compiled with an MS Visual Studio version that defines
_WIN32.
Unless tzname - *without* the leading underscore - is defined in <time.h> in
such a way that the CMake check for it succeeds, HAVE_TZNAME shouldn't be
defined, and, unless Windows has tm_zone in struct tm - which it shouldn't have
- or the CMake check for that incorrectly says "yes", HAVE_STRUCT_TM_TM_ZONE
shouldn't be defined, either, in which case the "Windows C Runtime" code should
be used.
> Note:
> When I open a logfile captured in a different timezone, then timezone
> will show MESZ/MEZ for me as arrival timezone. Which is at least not
> correct, as struct tm (from windows time.h) contains no information
> about the timezone or gmt-offset.
It's not showing the arrival time zone.
It's showing *your* time zone.
It's showing that the time values it's displaying correspond to times in what I
presume is *your* time zone. Think of the explicit display of MESZ/MEZ as the
time zone as a *warning* that these aren't necessarily the times in the time
zone in which the packets were captured.
The time zone in which the file was captured is *not* recorded in most (all?)
packet capture formats, so, unless the time stamps happen to be local time
stamps rather than UTC time stamps, Wireshark (and tcpdump and TShark and so
on) *cannot* show what the packet arrival time was in the time zone in which
the packets were captured. pcap and pcapng files store UTC time stamps, and
don't store time zone information, so, unless the time zone in which the
capture was made is provided to the program dissecting the packets, it *can't*
show the packet arrival times in any time zone other than UTC or *your* local
time zone.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
