See the following snippet: #include <time.h> #include <stdlib.h> int main() { time_t t; struct tm tmp; char str[200]; t = time(NULL); tmp = *gmtime(&t); tmp.tm_gmtoff = 0; tmp.tm_zone = NULL; strftime(str, sizeof(str), "%Z", &tmp); puts(str); t = -2461446500; localtime(&t); t = time(NULL); tmp = *gmtime(&t); tmp.tm_gmtoff = 0; tmp.tm_zone = NULL; strftime(str, sizeof(str), "%Z", &tmp); puts(str); return 0; } Output here is: CET PMT After a bit of digging, it seems the external variable "tzname" gets (wrongly) mutated by the localtime() call. The "%Z" format specifier just reuses that info. This issue got reproduced on several distributions, see http://bugs.python.org/issue13309
By overwriting tm_gmtoff and tm_zone the struct tm is no longer valid.
These fields are "overwritten" by hand in the example for ease of reproduction. The actual use case is to fill the members of a struct tm by hand from user data. Since tm_gmtoff and tm_zone are not specified by POSIX, they are left alone, zero-filled (the struct is previously initialized with memset()). There's no portable way that I know of to initialize these fields. While the most basic use of strftime() indeed consists in formatting a struct tm returned by a libc function (such as gmtime()), it seems reasonable to use strftime() to format user-defined time data. Nowhere does POSIX seem to say that the struct tm *has* to come from gmtime() or similar functions.