On 11/01/2017 01:12 PM, Zefram wrote:
localtime() operates on a time_t, the value of which you need to get from time() or from the .tv_sec part of what you get from gettimeofday(). Instead you've taken a correct .tv_sec and multiplied it by 1000. Instead of asking about November 2017 you've asked about October 49804. A zero offset is still not what the tzdb projects for 49804, but localtime() can be forgiven for giving up.
Although that is indeed a problem with the program, I suspect that there's some other issue as well. I just now compiled and ran the following simpler variant of the program on Fedora 26 x86-64 (64-bit long and time_t), linked to the current tzdb code and data: #include <time.h> #include <stdio.h> int main (void) { time_t time = 1509521131510; long long ltime = time; struct tm *tm = localtime (&time); printf ("epoch:%lld, %lld-%02d-%02d %02d:%02d:%02d gmtoff: %ld, TZ: %s\n", ltime, tm->tm_year + 1900LL, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec, tm->tm_gmtoff, tm->tm_zone); return 0; } With the TZ environment variable set to "Asia/Manila", it outputs the expected value: epoch:1509521131510, 49804-10-27 17:25:10 gmtoff: 28800, TZ: +08 With the TZ environment variable unset, it outputs: epoch:1509521131510, 49804-10-27 09:25:10 gmtoff: 0, TZ: GMT which are the reported symptoms. But the latter output is also correct, since the default wall-clock time, if you just install tzdb without any special configuration and do not set TZ, is the same as if you had set TZ="GMT0".