[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