[PROPOSED] Draft next POSIX has tm_gmtoff, tm_zone
* private.h (TM_GMTOFF, TM_ZONE): Treat draft next POSIX like glibc etc., since it requires tm_gmtoff and tm_zone. --- private.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/private.h b/private.h index 07316289..8eff90b7 100644 --- a/private.h +++ b/private.h @@ -768,7 +768,8 @@ time_t posix2time(time_t); /* Infer TM_ZONE on systems where this information is known, but suppress guessing if NO_TM_ZONE is defined. Similarly for TM_GMTOFF. */ -#if (defined __GLIBC__ \ +#if (200809 < _POSIX_VERSION \ + || defined __GLIBC__ \ || defined __tm_zone /* musl */ \ || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ || (defined __APPLE__ && defined __MACH__)) -- 2.40.1
On 1/13/24 16:01:23, Paul Eggert via tz wrote:
* private.h (TM_GMTOFF, TM_ZONE): Treat draft next POSIX like glibc etc., since it requires tm_gmtoff and tm_zone. --- I wrote an exercise testing the effect of changing struct tm and TZ after local time() and before strftime() and mktime((). It works as I intended on MacOS and Linux. I'll try to attach it. Output is:
2024 1705248193 1705248193 2424 14328028993 14328028993 Average days in year = 365.24250 America/New_York is ahead of America/Los_Angeles by 3.00 hours. I hope the PROPOSED changes don't modify this. -- gil
On 2024-01-14 08:16, Paul Gilmartin via tz wrote:
I hope the PROPOSED changes don't modify this.
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.
On 1/14/24 12:48:01, Paul Eggert via tz wrote:
On 2024-01-14 08:16, Paul Gilmartin via tz wrote:
I hope the PROPOSED changes don't modify this.
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.
I was trying to illustrate the question: 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 which I may need elsewhere in my program? It must not depend on setting struct tm members which I want the library functions to compute. -- gil
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.
participants (2)
-
Paul Eggert -
Paul Gilmartin