On 11/16/23 14:43, Guy Harris wrote:
(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.
So even POSIX, in effect, tells people "don't assume tm_isdst means 'this is daylight saving time'".
Not sure what is meant by "in effect". POSIX says "The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available." <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html> So the intent of POSIX is that tm_isdst>0 means daylight saving time. The DST offset from UT need not be greater than the standard-time offset. POSIX (and TZDB) even allow the two offsets to be equal, though there's not much use for that.
POSIX does not appear to require that tzname[0] or tzname[1] retain the same values over time
That's true if you set TZ to a value like 'America/Detroit' because POSIX doesn't specify the behavior for such TZ settings. However, if you set TZ to a POSIX-specified value like 'IST-1GMT0,M10.5.0,M3.5.0/1' then tzname[0] and tzname[1] have specified values - in this case, "IST" and "GMT" respectively. By the way, Draft 3 of the next POSIX standard requires support for TZDB Zones, e.g., TZ='Europe/London'.
Requiring tm_zone may cause binary-compatibility issues for OSes that don't currently have it and for which the supplier seeks Single UNIX Specification certification.
There definitely are binary compatibility issues, since growing a struct is a hassle. This is true regardless of whether the system is SUS certified.
That would raise the question of how long-lived a struct tm is.
That's reasonably straightforward. With localtime the char * member's lifetime survives until TZ is modified; this is what Draft 3 of the next POSIX standard says. On platforms with localtime_rz the member survives until the corresponding timezone_t is tzfree'd. In hindsight perhaps tm_zone should have been char[TZNAME_MAX + 1] as that solves the lifetime problem (and lessens the temptation to read too much into those abbreviations :-), but it's too late to change this now.