On 01/25/2018 08:05 PM, Paul Eggert wrote:
On 01/25/2018 04:52 PM, Guy Harris wrote:
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.)
I apologize for going further off topic, but I've long had a question about this. Rather than requiring applications to "call localtime and gmtime ... and subtract the results by hand", why couldn't the function(s) used by tzset for the tm_gmtoff value be made available for applications? That is, offer an API to get the offset directly from TZ/tzfile, instead of relying on complex and imprecise math (e.g., the glibc comment: it's OK to assume that A and B are close to each other). I just recently had to add this tm_diff() math to util-linux, it seems unnecessary to require this duplication. BTW, I think the information in the message that I'm replying to is very useful. Perhaps it should be documented in the glibc manual and elsewhere?