<div dir="ltr">On Thu, Dec 14, 2023 at 6:23 AM Aharon Robbins <<a href="mailto:arnold@skeeve.com">arnold@skeeve.com</a>> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi All.<br>
<br>
This is a bit off-topic, but people here are likely to know the answer.<br></blockquote><div><br></div><div>tl;dr: FreeBSD retains the old timezone() function because the 4BSD series</div><div>of releases had it. Other, more modern interfaces are available, but it can</div><div>be a PITA. It's an XSI-only variable, but one of the few that FreeBSD does</div><div>not provide.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
V7 had a timezone function:<br>
<br>
        char *timezone(int zone, int dst);<br>
<br>
that returned a timezone name.</blockquote><div><br></div><div>Yes. These were compile-time constants of some kind</div><div><br></div><div>        4*60, "AST", "ADT",             /* Atlantic */<br>        5*60, "EST", "EDT",             /* Eastern */<br>        6*60, "CST", "CDT",             /* Central */<br>        7*60, "MST", "MDT",             /* Mountain */<br>        8*60, "PST", "PDT",             /* Pacific */<br>        0, "GMT", 0,                    /* Greenwich */</div><div><br></div><div>with the comment</div><div> * Sorry, I don't know all the names.                                                                                                                                                                                                       <br></div><div><br></div><div>which is (a) not helpful and (b) wrong in the case of GMT (even at the time</div><div>V7 was released, the official name was UTC for the non-shifting version).</div><div><br></div><div>This function is only slightly changed to include a couple of more timezones</div><div>and has the warning in the man page:</div><div>     This interface is for compatibility only; it is impossible to reliably<br>     map timezone's arguments to a time zone abbreviation.  See ctime(3).<br><br></div><div>This function should never be used.</div><div><br></div><div>BSD has had a timezone argument to gettimeofday for a long time.</div><div>It used to return the compiled-in offset from GMT(sic), but that option</div><div>has been eliminated.</div><div><br></div><div>The more reliable tzset() function has replaced all of that. It describes</div><div>how the TZ variable, if set, is used and where to find information about</div><div>the timezone files.</div><div><br></div><div>To get the local offset, you need to compare gmtime() to localtime(),</div><div>though most of the time you want to use asctime to format times, or</div><div>better, strftime(3).</div><div><br></div><div>There's extern char *tzname[2] that exports the timezone name(s) from</div><div>the tzcode that's the companion to what's now the IANA TZ database</div><div>(aka the olson database).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> POSIX has a timezone variable which is<br>
the offset in seconds from UTC.<br></blockquote><div><br></div><div>It' is an optional part of POSIX, though, it's part of<br></div><div>XSI_C_LANG_SUPPORT: XSI General C Library<br>a64l( ), daylight, drand48( ), erand48( ), ffs( ), ffsl( ), ffsll( ), getdate( ), hcreate( ), hdestroy( ),<br>hsearch( ), initstate( ), insque( ), jrand48( ), l64a( ), lcong48( ), lfind( ), lrand48( ), lsearch( ),<br>memccpy( ), mrand48( ), nrand48( ), random( ), remque( ), seed48( ), setstate( ), signgam,<br>srand48( ), srandom( ), strptime( ), swab( ), tdelete( ), tfind( ), timezone, tsearch( ), twalk( )</div><div><br></div><div>So properly, should only be visible when XSI has been requested (or</div><div>when everything has been requested).</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The man pages for all of {Net,Free,Open}BSD seem to indicate that both<br>
are available on those systems.<br></blockquote><div><br></div><div>timezone, the variable, isn't available on FreeBSD. It's not declared anywhere.</div><div>Only timezone, the massively obsolete compatibility function is defined in</div><div>time.h. I believe neither is the 'daylight' variable.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My question is, how? The declarations for both are given as being in <time.h>.<br>
But don't the symbols in libc.a conflict with each other? How does a programmer<br>
on *BSD choose which version of timezone they will get?<br></blockquote><div><br></div><div>Generally, the programmer should choose to use other, more modern interfaces. :)<br></div><div>timezone, the function, is about useless. To get the offset, you need to get the</div><div>current time (or the time you are interested in) as a time_t. You'd then call</div><div>localtime with that time_t to get a struct tm and them timegm with that tm</div><div>to get localtime as a time_t. Subtract the original time from the result to get seconds</div><div>west of UTC.</div><div><br></div><div>Arguably BSDs should just support the timezone variable, but that's hard when there's</div><div>also a function. You'd likely want it more often than the function, but you also want old</div><div>code that's referenced it to work too. The code is there, butdisabled in tzconfig.h due</div><div>to the conflict.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Feel free to reply privately.<br>
<br>
Thanks,<br>
<br>
Arnold<br>
</blockquote></div></div>