gmtime_r sets the tm_zone field to a wrong value

[bhaible]

The gmtime_r and localtime_r functions return information about the time zone in the fields tm_gmtoff and tm_zone. For gmtime_r, this time zone should be UTC (equivalent to GMT), because POSIX ​https://pubs.opengroup.org/onlinepubs/9799919799/functions/gmtime.html says: "Upon successful completion, gmtime_r() shall return the address of the structure pointed to by the argument result. The structure's tm_zone member shall be set to a pointer to the string "UTC", which shall have static storage duration."

This does not work in Haiku hrev57823 (from 2024-07-15).

How to reproduce:

Time preferences > Date and Time > Time zone > Set to Germany Time.

Compile and run the attached program foo.c.

gcc -Wall foo.c
./a.out

Expected output:

tm_zone = UTC
OK

or

tm_zone = GMT
OK

Actual output:

tm_zone = GMT+1
a.out: foo.c:26:main: strcmp (result->tm_zone, "GMT") == 0 || strcmp (result->tm_zone, "UTC") == 0
Kill Thread

[bhaible]

test case foo.c

[waddlesplash]

Fixed in hrev58061 +beta5.

[bhaible]

Does your fix also work when the user is in London time zone, i.e. currently British Summer Time?

In other words, can the line

	if (tmOut->tm_gmtoff == -*fDataBridge->addrOfTimezone) {

correctly distinguish GMT (= UTC) and the London time zone, which has GMT offset 0 in the winter and 1 in the DST period (March to October)?

[waddlesplash]

My current timezone is a DST one, and this worked on my system. It appears that the timezone offset will be the DST timezone offset in this case, and *addrOfDaylight will then be 1.

[bhaible]

It appears that the timezone offset will be the DST timezone offset in this case, and *addrOfDaylight will then be 1.

Well, then you have a bug in the Azores Summer Time.

Look at ​https://www.timeanddate.com/time/zone/uk/edinburgh ​https://www.timeanddate.com/time/zone/portugal/ponta-delgada-azores compared to ​https://www.timeanddate.com/time/zone/timezone/utc

[waddlesplash]

Indeed so, fixed that in hrev58062.