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.