From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18440 invoked from network); 14 Dec 2023 17:29:12 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 14 Dec 2023 17:29:12 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7087B43E79; Fri, 15 Dec 2023 03:29:07 +1000 (AEST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by minnie.tuhs.org (Postfix) with ESMTPS id 7E7F043E78 for ; Fri, 15 Dec 2023 03:29:02 +1000 (AEST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-50bf1e32571so9818687e87.2 for ; Thu, 14 Dec 2023 09:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1702574941; x=1703179741; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NGOipKS1UneVBCDBqmhdjIi0POOmo+rZ+QNfpgciLII=; b=G4y+EUE24CdYWJRJjiTBXNOTkj34oNtvPbCFictoZSPuuvH0yccmuqWbcdFs9BQjyS 7naUDkZjruvOzn/WfMg5oCRDvRYz3HNgG0eED3mkiqtavj09wlSzUNV5pPT2b3BK7AYw o3jDAN+NMa3PPlbHRxvqRRhqoOglss2dCJw4XPw5OwMLxyDOEiMUfC7MqxMw7twgmq5y ydweI+ZIh3IXIMpUsJv/9abWusGgUrNpI84RubETVeYCe6qa3lEmHneontD7Ni+qBTr+ DCankzNR/exy5az9+aq1Bi5dJlZf0K/A1aFz972JaY8M3fWEhbsSJuLmVsVfKbZ8PFb7 fHBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702574941; x=1703179741; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NGOipKS1UneVBCDBqmhdjIi0POOmo+rZ+QNfpgciLII=; b=tR+k68JTFDkOz3mChx+LPxYL5jd9POYiJRPCKtLiDMw43BYyLhbTHAn6YyUdj8JriL PWbEj77dBjIQZOulBk4t3R2Vpp15j/cEs1dPLD+9wz0DRaRnz8+Ahiqfk7qDaDhFGXD4 RLQEIcjJsv7kxqPGLBmSLexXZRb5fROQ5xjOntOnhaYLfboB75cDan7X1sPd2YHVJf1D oEuvS0sUC1MvutL61ZzbsLV/9kDtz3opIJpuDTBncQcNP4pDTUSTJF8T0X1f/V5bjUlm 9yloXeFDVfXVikAPVlQYX/Sn5Qdp6AJAWkrujjtuW4cMVINs5zuPktWMRcwnBPIVVKq8 wiZw== X-Gm-Message-State: AOJu0YyXnKg27SJcXvNqJuTUxOuFXJSZ60X1LIMNm9sogtKzC/plTrGP JhjLr8s/U4Gha0/uF/w2ODFWkJ+7xBep5sinJoxamR323JcvWQinqWA= X-Google-Smtp-Source: AGHT+IE4+m9RkbhQSfeTHp1uuhncAnJgmntBqJ8KE+61vx1/mLNZYEdpoDT/CmVRak9RMCdcH2crw78xiqOgHiZF/K4= X-Received: by 2002:a05:6512:b89:b0:50c:58d:8b6 with SMTP id b9-20020a0565120b8900b0050c058d08b6mr6714960lfv.89.1702574940542; Thu, 14 Dec 2023 09:29:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 14 Dec 2023 10:28:56 -0700 Message-ID: To: Aharon Robbins Content-Type: multipart/alternative; boundary="00000000000088e816060c7b9e14" Message-ID-Hash: WVUNXNKAFXZSGI64TGVEJVM34CWXMEW6 X-Message-ID-Hash: WVUNXNKAFXZSGI64TGVEJVM34CWXMEW6 X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Off topic: BSD timezone function vs. POSIX timezone variable List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000088e816060c7b9e14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2023 at 6:23=E2=80=AFAM Aharon Robbins = wrote: > Hi All. > > This is a bit off-topic, but people here are likely to know the answer. > tl;dr: FreeBSD retains the old timezone() function because the 4BSD series of releases had it. Other, more modern interfaces are available, but it can be a PITA. It's an XSI-only variable, but one of the few that FreeBSD does not provide. > V7 had a timezone function: > > char *timezone(int zone, int dst); > > that returned a timezone name. Yes. These were compile-time constants of some kind 4*60, "AST", "ADT", /* Atlantic */ 5*60, "EST", "EDT", /* Eastern */ 6*60, "CST", "CDT", /* Central */ 7*60, "MST", "MDT", /* Mountain */ 8*60, "PST", "PDT", /* Pacific */ 0, "GMT", 0, /* Greenwich */ with the comment * Sorry, I don't know all the names. which is (a) not helpful and (b) wrong in the case of GMT (even at the time V7 was released, the official name was UTC for the non-shifting version). This function is only slightly changed to include a couple of more timezone= s and has the warning in the man page: This interface is for compatibility only; it is impossible to reliably map timezone's arguments to a time zone abbreviation. See ctime(3). This function should never be used. BSD has had a timezone argument to gettimeofday for a long time. It used to return the compiled-in offset from GMT(sic), but that option has been eliminated. The more reliable tzset() function has replaced all of that. It describes how the TZ variable, if set, is used and where to find information about the timezone files. To get the local offset, you need to compare gmtime() to localtime(), though most of the time you want to use asctime to format times, or better, strftime(3). There's extern char *tzname[2] that exports the timezone name(s) from the tzcode that's the companion to what's now the IANA TZ database (aka the olson database). > POSIX has a timezone variable which is > the offset in seconds from UTC. > It' is an optional part of POSIX, though, it's part of XSI_C_LANG_SUPPORT: XSI General C Library a64l( ), daylight, drand48( ), erand48( ), ffs( ), ffsl( ), ffsll( ), getdate( ), hcreate( ), hdestroy( ), hsearch( ), initstate( ), insque( ), jrand48( ), l64a( ), lcong48( ), lfind( ), lrand48( ), lsearch( ), memccpy( ), mrand48( ), nrand48( ), random( ), remque( ), seed48( ), setstate( ), signgam, srand48( ), srandom( ), strptime( ), swab( ), tdelete( ), tfind( ), timezone, tsearch( ), twalk( ) So properly, should only be visible when XSI has been requested (or when everything has been requested). The man pages for all of {Net,Free,Open}BSD seem to indicate that both > are available on those systems. > timezone, the variable, isn't available on FreeBSD. It's not declared anywhere. Only timezone, the massively obsolete compatibility function is defined in time.h. I believe neither is the 'daylight' variable. > My question is, how? The declarations for both are given as being in > . > But don't the symbols in libc.a conflict with each other? How does a > programmer > on *BSD choose which version of timezone they will get? > Generally, the programmer should choose to use other, more modern interfaces. :) timezone, the function, is about useless. To get the offset, you need to get the current time (or the time you are interested in) as a time_t. You'd then call localtime with that time_t to get a struct tm and them timegm with that tm to get localtime as a time_t. Subtract the original time from the result to get seconds west of UTC. Arguably BSDs should just support the timezone variable, but that's hard when there's also a function. You'd likely want it more often than the function, but you also want old code that's referenced it to work too. The code is there, butdisabled in tzconfig.h due to the conflict. > Feel free to reply privately. > > Thanks, > > Arnold > --00000000000088e816060c7b9e14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 14, 2023 at 6:23=E2=80=AFAM Aharon Robbins <= ;arnold@skeeve.com> wrote:
Hi = All.

This is a bit off-topic, but people here are likely to know the answer.
=

tl;dr: FreeBSD retains the old timezone() = function because the 4BSD series
of releases had it. Other, more = modern interfaces are available, but it can
be a PITA. It's a= n XSI-only variable, but one of the few that FreeBSD does
not pro= vide.
=C2=A0
V7 had a timezone function:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 char *timezone(int zone, int dst);

that returned a timezone name.

Yes. These w= ere compile-time constants of some kind

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 4*60, "AST", "ADT", =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 /* Atlantic */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 5*60= , "EST", "EDT", =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 /* Eastern */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 6*60, "CST", &qu= ot;CDT", =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Central */
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 7*60, "MST", "MDT", =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Mountain */
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 8*60, "PST", "PDT", =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /* Pacific */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0, "GMT&quo= t;, 0, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/* Greenwich */

with the comment
=C2= =A0* Sorry, I don't know all the names. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br>

which is (a) not helpful and (b) wrong in the = case of GMT (even at the time
V7 was released, the official name = was UTC for the non-shifting version).

This functi= on is only slightly changed to include a couple of more timezones
and has the warning in the man page:
=C2=A0 =C2=A0=C2=A0 This in= terface is for compatibility only; it is impossible to reliably
=C2=A0 = =C2=A0 =C2=A0map timezone's arguments to a time zone abbreviation.=C2= =A0 See ctime(3).

This function should never be used.

BSD has had a timezone argument to gettimeofday for a= long time.
It used to return the compiled-in offset from GMT(sic= ), but that option
has been eliminated.

= The more reliable tzset() function has replaced all of that. It describes
how the TZ variable, if set, is used and where to find information= about
the timezone files.

To get the lo= cal offset, you need to compare gmtime() to localtime(),
though m= ost of the time you want to use asctime to format times, or
bette= r, strftime(3).

There's extern char *tzname[2]= that exports the timezone name(s) from
the tzcode that's the= companion to what's now the IANA TZ database
(aka the olson = database).
=C2=A0
POSIX has a timezone variable which is
the offset in seconds from UTC.

It'= is an optional part of POSIX, though, it's part of
XSI_C= _LANG_SUPPORT: XSI General C Library
a64l( ), daylight, drand48( ), eran= d48( ), ffs( ), ffsl( ), ffsll( ), getdate( ), hcreate( ), hdestroy( ),
= hsearch( ), initstate( ), insque( ), jrand48( ), l64a( ), lcong48( ), lfind= ( ), lrand48( ), lsearch( ),
memccpy( ), mrand48( ), nrand48( ), random(= ), remque( ), seed48( ), setstate( ), signgam,
srand48( ), srandom( ), = strptime( ), swab( ), tdelete( ), tfind( ), timezone, tsearch( ), twalk( )<= /div>

So properly, should only be visible when XSI has b= een requested (or
when everything has been requested).

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> The man pages for all of {Net,Free,Open}BSD seem to indicate that both
are available on those systems.

timezon= e, the variable, isn't available on FreeBSD. It's not declared anyw= here.
Only timezone, the massively obsolete compatibility functio= n is defined in
time.h. I believe neither is the 'daylight= 9; variable.
=C2=A0
My question is, how? The declarations for both are given as being in <ti= me.h>.
But don't the symbols in libc.a conflict with each other? How does a pr= ogrammer
on *BSD choose which version of timezone they will get?

Generally, the programmer should choose to use other, more= modern interfaces. :)
timezone, the function, is about usele= ss. To get the offset, you need to get the
current time (or the t= ime you are interested in) as a time_t. You'd then call
local= time with that time_t to get a struct tm and them timegm with that tm
=
to get localtime as a time_t. Subtract the original time from the resu= lt to get seconds
west of UTC.

Arguably = BSDs should just support the timezone variable, but that's hard when th= ere's
also a function. You'd likely want it more often th= an the function, but you also want old
code that's referenced= it to work too. The code is there, butdisabled in tzconfig.h due
to the conflict.
=C2=A0
Feel free to reply privately.

Thanks,

Arnold
--00000000000088e816060c7b9e14--