[Guy Harris <guy@xxxxxxxxxxxx>]

On Dec 31, 2016, at 11:08 AM, Thomas Wiens <th.wiens@xxxxxx> 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.