On 01/25/2018 04:52 PM, Guy Harris wrote:
1) applications should not require a knowledge of "the" offset from UTC (given that there may not be any such thing as "the" offset from UTC), e.g. don't use timezone;
Yes.
2) applications that need to know offset from UTC at any given instance should do so by doing strftime(buf, bufsize, "%z", tm) and parsing the result;
Sort of. That method works only if the UTC offset is a multiple of 1 minute. This is a safe assumption for modern civil timestamps, but if you want to go back before 1972 in tzdb, or if you want to support odd-but-valid POSIX TZ strings, a more-reliable approach is to call localtime and gmtime on the same timestamp, and subtract the results by hand with the usual Gregorian rules. (And yes, that's what some applications do - of course it's much easier and faster to use tm_gmtoff when available.)
3) applications that need to know the the time zone abbreviation at any given instance should do so by doing strftime(buf, bufsize, "%Z", tm);
Yes.
4) applications should not require a knowledge whether daylight savings time (or whatever it's called) has ever been, or will ever be, in effect in the current locale/tzdb region.
Yes.
What, in real-world terms, can they assume about tm_isdst? That it indicates some either implementation-specified or unspecified notion of "Daylight Saving{s} Time", which might or might not be set e.g. during a Ramadan time shift? Or that it's true iff the time is shifted from some implementation-specified or unspecified notion of "standard time" (which might not, in the Republic of Ireland, correspond to Irish Standard Time)?
Portable code shouldn't use tm_isdst; it's a vestigial interface. Alas, too many programs do use it, I think mostly because programmers not-unnaturally think it must exist for a reason.