Hi! On Tue, Jul 19, 2022 at 02:17:15PM +0200, Alejandro Colomar wrote: > On 7/19/22 03:56, наб wrote: > > glibc cited for __USE_MISC, tm_zone invalidation is Debian 2.33-7 > > But I guess it is present in much older glibcs, right? > Otherwise we should add a VERSIONS thingy. The fields appear in the glibc git root commit 28f540f45bbacd939bfd07f213bcad2bf730b1bf ("initial import"); the ChangeLog entry for them is Mon Apr 6 01:39:07 1992 Roland McGrath (roland@geech.gnu.ai.mit.edu) time/time.h (struct tm): Add `tz_gmtoff', `tz_zone'. This was 30 years ago, so I don't think we need to version it. For the macro requirements, blame on the glibc git points to -- >8 -- @@ -110,8 +110,14 @@ struct tm int tm_wday; /* Day of week. [0-6] */ int tm_yday; /* Days in year.[0-365] */ int tm_isdst; /* DST. [-1/0/1]*/ - long int tm_gmtoff; /* Seconds west of UTC. */ + +#ifdef __USE_BSD + long int tm_gmtoff; /* Seconds east of UTC. */ __const char *tm_zone; /* Timezone abbreviation. */ +#else + long int __tm_gmtoff; /* Seconds east of UTC. */ + __const char *__tm_zone; /* Timezone abbreviation. */ +#endif }; -- >8 -- from f0f1bf8536fe660cb6230a22694f9b7e6b02605e ("update from main archive 960911"), dated Thu Sep 12 02:51:03 1996 +0000; the relevant message chunk is 1996-09-11 Paul Eggert * time/time.h (tm_gmtoff, tm_zone): Prefix with `__' unless __USE_BSD; this is required for ANSI C compatibility. for the origin. (I realise now __USE_BSD corresponds to just _BSD_SOURCE, which didn't match the template I copied, so I updated that for v2). This was replaced with __USE_MISC in 498afc54dfee41d33ba519f496e96480badace8e ("Combine __USE_BSD and __USE_SVID into __USE_MISC."): -- >8 -- @@ -142,7 +142,7 @@ struct tm int tm_yday; /* Days in year.[0-365] */ int tm_isdst; /* DST. [-1/0/1]*/ -# ifdef __USE_BSD +# ifdef __USE_MISC long int tm_gmtoff; /* Seconds east of UTC. */ const char *tm_zone; /* Timezone abbreviation. */ # else -- >8 -- which is contained in every tag since glibc-2.20, the relevant part of which says: -- >8 -- * The _BSD_SOURCE and _SVID_SOURCE feature test macros are no longer supported; they now act the same as _DEFAULT_SOURCE (but generate a warning). Except for cases where _BSD_SOURCE enabled BSD interfaces that conflicted with POSIX (support for which was removed in 2.19), the interfaces those macros enabled remain available when compiling with _GNU_SOURCE defined, with _DEFAULT_SOURCE defined, or without any feature test macros defined. -- >8 -- (I've also updated the f_t_m(7) box to say >=2.20: _D_S, <2.20: _B_S.) > > This also fixes the multiple lies in man-pages 5.10 localtime(3), > > which says only: > Did you forget that removal of lies? I don't see it in the patch. I've updated the commit message for v2 to be less misleading, the removal is in 5/5 > > > > Signed-off-by: Ahelenia Ziemiańska > > --- > > man3/tm.3type | 45 +++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 45 insertions(+) > > > > diff --git a/man3/tm.3type b/man3/tm.3type > > index 1931d890d..8b6f8d9bf 100644 > > --- a/man3/tm.3type > > +++ b/man3/tm.3type > > @@ -25,8 +25,26 @@ Standard C library > > .BR " int tm_yday;" \ > > " /* Day of the year [" 0 ", " 365 "] (Jan/01 = " 0 ") */" > > .BR " int tm_isdst;" " /* Daylight savings flag */" > > + > > +.BR " long tm_gmtoff;" " /* Seconds East of UTC */" > > +.BR " char*tm_zone;" " /* Timezone abbreviation */" > > Please add cosmetic whitespace (at least 1 for every member, possibly 2, > depending on your taste) :) Added to match the classic long f1; int *f2; layout. > > +.I tm_gmtoff > > +is the difference, in seconds, of the timezone represented by this broken-down time and UTC > > +(this is the reverse of > > Could you come up with a more mathematically precise term for "reverse"? > What is reverse? The additive inverse? Maybe use "additive inverse"? I > think "opposite" also has the meaning of additive inverse in maths, and it's > maybe a simpler term (although additive inverse is more precise, IMHO). But > reverse is definitely confusing to me. ::timezone is seconds West, struct tm::tm_gmtoff is seconds East, so they have the opposite sign. I was also not a fan of "reverse", but couldn't come up with a good english term for it; a skim of a technical terms dictionary points to Additive inverse (negation) Multiplicative inverse (reciprocal) but the wiktionary confirms my inkling that "negation" doesn't work here. "Opposite" may work since we (and POSIX) define this as cur - UTC (well, POSIX ::timezone in the opposite (hehe) order as UTC - cur), but that may not be obvious. "Additive inverse" works, IMO, yeah. Updated. > > +.BR timezone (3), > > +as a variable, is an XSI extension \(em some systems provide the V7-compatible > I tend to prefer the em dash to be next to (no whitespace) the enclosed > clause. That makes it easier to mentally associate (as in a set of > parentheses) to the clause. I'm not sure if it's a thing of mine, or if > it's standard practise? Dunno; I'd, personally never seen unspaced dashes in Polish and the vast majority of modern English and French. Conversely, archaic documents I've seen tend to prefer dashes touching the surrounding text directly, so I'd assume this were regional, especially in languages genetically close to Latin. Replaced with a colon instead. > > +.I tm_zone > > +points to potentially-constant static storage and may be overriden on subsequent calls to > > +.BR localtime (3) > > +&a. (this, however, never happens under glibc). > What is "&a."? Is that documented somewhere? I didn't know that > abbreviature. That's an archaic form of "and others" (&a. -> &al. -> et al. -> et alia), I didn't even notice :v Replaced with "and similar functions" (this includes localtime_r() and, depending on the libc, gmtime*(), &c.). Best, наб