On 2023-11-13 16:48, Guy Harris wrote:
I see three ways in which tm_isdst can be used:
1) as an indication of whether something known as "daylight saving time" or "summer time" or something other than "standard time" is in effect;
2) as an indication of whether the offset-from-UTC is advanced from what it would be in winter;
3) as an index into the tzname[] array.
(1) is the only thing that tzcode supports. (2) is incompatible with POSIX if by "advanced" one means "greater offset from UT", since POSIX requires so-called "negative" DST for TZ settings like TZ='IST-1GMT0,M10.5.0,M3.5.0/1', the current Irish practice. (3) might be made to work, but it'd mean that in most TZDB Zones, tm_isdst would be nonzero for timestamps that pretty much everybody would consider to be standard time. For example, tzdata says TZ='America/Detroit' has observed standard time with abbreviations "LMT", "CST", and "EST" in the past, and at most one of these could get tm_isdst==0. Besides, with tzcode time zone abbreviations should not be deduced by inspecting tm_isdst. Instead, one should use strftime or (if available) the tm_zone member of struct tm. tm_zone is better if it is available, which I hope will be required by the next POSIX version. This is why <https://data.iana.org/time-zones/theory.html#vestigial> says "tm_isdst is almost never needed". Its only plausible use these days is when calling mktime, and even then it's flaky.