A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1788 ====================================================================== Reported By: Guy Harris Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1788 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Guy Harris Organization: User Reference: Section: N/A Page Number: N/A Line Number: N/A Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2023-11-18 00:16 UTC Last Modified: 2023-11-24 02:46 UTC ====================================================================== Summary: The meaning of "Daylight Saving Time" should be clarified ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001253 clarify that "alternative time&quo... ======================================================================
---------------------------------------------------------------------- (0006589) Guy Harris (reporter) - 2023-11-24 02:46 https://austingroupbugs.net/view.php?id=1788#c6589 ---------------------------------------------------------------------- > If i grep(1) through (Free|Net|Open)BSD your use case seems superficial. If by "superficial" you mean "unnecessary in most cases", that's probably true, as most programs don't need to report time zone abbreviations. However, some programs do, which is why system provide either tzname[] or tm_zone at all. > In general people seem to go through time functions instead of direct additions. In general I suspect programs don't report time zone abbreviations. And the BSDs all provide tm_zone, so programs that are part of those OSes, and that need to report the time zone abbreviation, don't need to look at tzname[] *anyway*. But, if you need a time zone abbreviation, it's hard to go through a time function if there *is* no time function that returns a time zone abbreviation, as is the case on some UN\*Xes such as Solaris 2+/SunOS 5.x (which probably has it because AT&T wouldn't allow tm_zone into struct tm in SVR4 because it might break binary compatibility with SVR3; SunOS 4.x had tm_zone because it was added when tzdb support was put into 4.0). Systems *with* tm_zone can use localtime() to get the time zone abbreviation. > The python and perl languages i also looked at (perl also included in the list through OpenBSD though, .. a bit) have some use cases, like Perl's POSIX module. They presumably use tzname[] when they run on those UN*Xes that don't have tm_zone. Perhaps on those systems that do, they use that instead. > I see no usage of tzname in the servers i use for email, http, ssh, nor in the openssh library. Most of them probably either 1) don't need to report time zone abbreviations or 2) rely on strftime() to provide it. > In general i think what should be strived for is a reentrant ie multithread-aware interface where global constants and all the inter-dependencies the current interface has, with all its complicated rules, are not used at all. Such as localtime_r() with tm_zone in struct tm, which is what POSIX 202x Draft 3 appears to require, except that "If the tm structure member tm_zone is accessed after the value of TZ is subsequently modified, the behaviour is undefined." For most if not all cases where TZ is modified, something such as NetBSD localtime_rz - https://man.netbsd.org/ctime.3 - would handle this. > Simply obsoleting tzname and such from now at a moment's notice is a bit rigid. "obsoleting" is a less precise term than "deprecating", which is the term I used in my comment. If "obsoleting" means "recommending that something else be used, if possible", which I would (and did) call "deprecating", I seee nothing rigid at all about recommending that code that only needs to run on systems supporting POSIX 202x, and allowing code that needs to run on pre-POSIX-202x systems that lack tm_zone in struct tm. If "obsoleting" means "removing from POSIX, so that POSIX 202x systems need not provide it", *that* is too rigid, and it's also not anything that I recommended. Issue History Date Modified Username Field Change ====================================================================== 2023-11-18 00:16 Guy Harris New Issue 2023-11-18 00:16 Guy Harris Name => Guy Harris 2023-11-18 00:16 Guy Harris Section => N/A 2023-11-18 00:16 Guy Harris Page Number => N/A 2023-11-18 00:16 Guy Harris Line Number => N/A 2023-11-20 01:03 Don Cragun Note Added: 0006573 2023-11-20 01:04 Don Cragun Relationship added related to 0001253 2023-11-20 17:10 kre Note Added: 0006576 2023-11-22 19:40 Guy Harris Note Added: 0006583 2023-11-22 20:12 Guy Harris Note Added: 0006584 2023-11-22 20:35 steffen Note Added: 0006585 2023-11-22 20:37 steffen Note Added: 0006586 2023-11-22 21:07 Guy Harris Note Added: 0006587 2023-11-23 23:19 steffen Note Added: 0006588 2023-11-23 23:21 steffen File Added: grep-over-bsds.txt 2023-11-24 02:46 Guy Harris Note Added: 0006589 ======================================================================
