[tz] [PROPOSED] Draft next POSIX has tm_gmtoff, tm_zone

[Paul Eggert]

On 2024-01-14 12:14, Paul Gilmartin via tz wrote:
>> You're OK, as the proposed changes don't affect your program's 
>> behavior. Your program always initializes the struct tm values via 
>> localtime_r, and it doesn't mess with TZ between calling localtime_r 
>> and calling strftime.
>> .
> No, I deliberately (and subtly) modified tm_year outside
> localtime() to 2424-1900 by += 400.

Oh, didn't see that. You're still OK with that program, though, as it's 
still initializing all the struct tm members.


> If I knot from sources outside my program and can set only
> the members:
> int    tm_sec   Seconds [0,60].
> int    tm_min   Minutes [0,59].
> int    tm_hour  Hour [0,23].
> int    tm_mday  Day of month [1,31].
> int    tm_mon   Month of year [0,11].
> int    tm_year  Years since 1900.
> int    tm_isdst Daylight Savings flag.
> ... plus the TZ environment variable.
> 
> How can I compute the corresponding value of %s or
> seconds-since-the-epoch

The obvious longstanding way to get seconds since the epoch, and the way 
code invariably does that sort of thing, is to use mktime. The proposed 
change doesn't affect mktime's behavior.

Although the mktime interface in POSIX (whether POSIX-2017 or 
POSIX-202x/D4) does not work when standard time jumps back, that's a 
different problem and should be addressed separately from the strftime 
%s issue.