[tz] Regarding changes of time format the Philippines
Paul Eggert
eggert at cs.ucla.edu
Wed Nov 1 21:31:58 UTC 2017
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".
More information about the tz
mailing list