On 8/3/26 14:23, Mason Loring Bliss via tz wrote:
the new timezone line is breaking the timezone offset calculations gmtime(3) is doing
From the bug report at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1143499> that's not what is happening. gmtime is working fine. The original bug report itself has serious bugs, but even the fixed test program you supplied in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1143499#27> is wrong for several reasons. First, it calls mktime(gmtime(&t)) which is heading in the wrong direction: mktime is the inverse of localtime, not of gmtime. Second, it assumes that daylight saving time is always one hour in advance of standard time, but this is not always true. It is false this year for Pacific/Raratonga and for Europe/Dublin, for example. Third, it assumes that a time zone has just standard time with UT offset X, or daylight saving time with UT offset X+1 hour. But this is false for America/Vancouver, which this year has standard time with two UT offsets (-8 and -7 hours, respectively). There are other problems with it, but let's quit while we're ahead. Although you've noticed the bugs with America/Vancouver, there are bugs in other timezones as well, bugs people simply haven't noticed. There's a simple fix for that code. Don't use mktime(gmtime()) trick. It's attempting to discover the UT offset for a given time_t value. But that's easy: just call localtime and look at tm_gmtoff. Problem solved. And this approach is standardized (finally!) in POSIX.1-2024. Presumably the code in heirloom mailx was written long ago, before we could assume tm_gmtoff. At the very least if it's running on a platform like GNU/Linux that supports tm_gmtoff, it should use tm_gmtoff. It should resort to other approaches (e.g., call localtime and gmtime and subtract) only if that fails. It should never call mktime(gmtime(...)) as that is simply a recipe for trouble.