A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1533 ====================================================================== Reported By: steffen Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1533 Category: Base Definitions and Headers Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: steffen Organization: User Reference: Section: time.h Page Number: 425 Line Number: 14451 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2021-11-08 22:04 UTC Last Modified: 2022-02-06 11:37 UTC ====================================================================== Summary: struct tm: add tm_gmtoff (and tm_zone) field(s) ======================================================================
---------------------------------------------------------------------- (0005664) mirabilos (reporter) - 2022-02-06 11:37 https://austingroupbugs.net/view.php?id=1533#c5664 ---------------------------------------------------------------------- @kre I’ve switched tm_year to type time_t as part of the “make time_t 64-bit on i386” conversions in MirBSD, where binary backwards compatibility was a nōn-issue, on 2004-11-22. It was required to pass the mktime test of GNU autoconf as shipped in GNU CVS, at that time, and in general works better. The downside was the huge amount of patches needed to do… - res = fprintf(ofile, "%04d%02d%02d%02d%02d%02d %u %u %u %u %x ", - gtm->tm_year + 1900, gtm->tm_mon + 1, gtm->tm_mday, + res = fprintf(ofile, "%04lld%02d%02d%02d%02d%02d %u %u %u %u %x ", + (long long)gtm->tm_year + 1900LL, gtm->tm_mon + 1, gtm->tm_mday, gtm->tm_hour, gtm->tm_min, gtm->tm_sec, otype, otests, otries, osize, ogenerator); (example from OpenSSH) to all kinds of third-party software. As of this year, I’m in the process of reverting that; I’ve added suitable functionality to pass the GNU mktime test otherwise. (At the same time, though, I’m switching the other MirBSD architecture’s time_t to 64 bit, so I’ll lack the 32-bit case in the future. Not a bad thing, though.) For the record, we have… long tm_gmtoff; /* seconds offset from UTC to the east */ char *tm_zone; /* abbreviation of timezone name */ … probably for hysteric raisins, but I’m all in favour of const-correctness for new APIs (and am retrofitting them over existing APIs where I can, such as writev(2) use of struct iovec). Considering C’s desire to make operations on signed integers UB, I’d have preferred tm_gmtoff to be an int (whose minimum width is wider in POSIX anyway), but changing this now would probably be bad for many OSes. @steffen no, “struct tm” does not work with the “Christian” calendars, it works with the proleptic Gregorian calendar (e.g. tm_year has “years since 1900”, not the Gregorian year number (in which a year 0 did not exist) or Julian years from before the switchover (which differed by location anyway)), and I think this is sensible. Any timekeeping application going that far into the past will need to do its own conversions anyway (taking the location of the query into account to determine when the switch between Julian and Gregorian occurred, for example). Issue History Date Modified Username Field Change ====================================================================== 2021-11-08 22:04 steffen New Issue 2021-11-08 22:04 steffen Name => steffen 2021-11-08 22:04 steffen Section => time.h 2021-11-08 22:04 steffen Page Number => 425 2021-11-08 22:04 steffen Line Number => 14451 2021-11-21 22:28 steffen Note Added: 0005529 2021-11-22 09:47 geoffclare Note Added: 0005530 2021-11-22 10:12 geoffclare Note Added: 0005531 2021-11-22 10:50 geoffclare Note Added: 0005532 2021-11-22 15:26 steffen Note Added: 0005533 2021-11-22 15:36 steffen Note Added: 0005534 2022-02-03 16:58 shware_systems Note Added: 0005656 2022-02-03 17:32 Don Cragun Note Added: 0005657 2022-02-03 18:41 kre Note Added: 0005658 2022-02-03 22:18 steffen Note Added: 0005660 2022-02-06 11:37 mirabilos Note Added: 0005664 ======================================================================
