Guy Harris wrote:
Not all OSes can do that, however, as not all OSes with "struct tm" have "tm_zone" and "tm_gmtoff" members of that structure.
Yes, that's right, the proposal is tuned for platforms that have time zone info in struct tm. Unfortunately if a struct tm is bare-bones and lacks this info, NetBSD's strftime_z can misbehave on time zones that don't fall into the simple POSIX model, because it cannot deduce strictly from a bare-bones struct tm what the time zone or abbreviation was for a past time stamp. For example, suppose TZ='Africa/Tripoli' and a bare-bones struct tm says only 2012-11-10 01:30:00 with tm_isdst == 0. This is ambiguous: it could be EET and it could be CET, as Libya changed time zones at 02:00 and repeated that hour without observing DST either before or after the transition. In this example, NetBSD's strftime_z guesses when formatting %Z or %z, and sometimes guesses wrongly. But the proposed tm_strftime function won't guess and will do the right thing on NetBSD. (In writing the above paragraph I saw a minor infelicity in the proposed patch -- not really a bug per se, just inelegance -- and the first attached patch should fix that.) If and when tm_strftime support is added to barebones struct tm platforms, I suggest adding tm_gmtoff and tm_zone members to struct tm in the usual way that system data structures are extended. These members might be hidden (e.g., they might be called __tm_gmtoff or whatever). On platforms where it's too much trouble to extend struct tm, I suppose the tm_strftime function should simply be an alias for strftime, though it will continue to botch %Z and %z occasionally. The proposed patch also fixes a C11 compatibility bug in tzcode up through 2014f, where strftime (when compiled with -DTM_ZONE) may access a bad pointer when interpreting %Z or (when compiled with -DTM_GMTOFF) an uninitialized integer when interpreting %z, even though the C standard says the behavior must not be undefined. I forgot to document that fix in NEWS; second proposed patch attached.