Regarding changes of time format the Philippines
Hi , We are using tzdb for all our customers. With latest update of tzdb to 2017a, one of the customer came back with issue in time format display in logs. The timezone for this Customer is Asia/Manila i.e. Philippines. Before use on 2017a tzdb , the time displayed is as follows 2017-10-31 16:47:33.930 +0800 After using 2017a tzdb time displayed as 2017-10-31 08:48:38.056 +0000 We observed the same issue using perl DateTime module too. We could see that the time format for this zone is changed from PH%sT to +08/+09. This change is there only in asia file.(Note reverting back this change and recompiling tzdb resolves the issue) We are looking for a solution for this. We are not clear whether some dependent library needs to be upgraded , or it is a bug in tzdb. Kindly address the query and help to resolve the issue. Thanks & Regards, Arati =========================================================== Learn how to protect users, data, and applications with security engineered for the public cloud by Barracuda. http://barracuda.com DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. ===========================================================
I am not observing either problem on Fedora 26, which currently uses tzdb 2017b and Perl 5.24.3. I ran the following shell commands. Please try them on your platform. If they work for you, can you give examples of similar shell commands that fail for you? $ TZ=Asia/Manila date Wed Nov 1 01:52:50 +08 2017 $ TZ=Asia/Manila perl -E'use DateTime; say DateTime->now(time_zone=>"local")->strftime("%Y-%m-%d %H:%M:%S %z (%Z)");' 2017-11-01 01:53:22 +0800 (+08) $ perl -E'use DateTime; say DateTime->VERSION;' 1.43 $ perl -E'use DateTime; say DateTime::TimeZone->VERSION;' 2.13 If I change "local" to "floating", I get symptoms similar to what you report: $ TZ=Asia/Manila perl -E'use DateTime; say DateTime->now(time_zone=>"floating")->strftime("%Y-%m-%d %H:%M:%S %z (%Z)");' 2017-10-31 17:57:03 +0000 (floating) However, this is what "floating" is supposed to do, and it does the same thing if TZ="America/Los_Angeles".
Thank you Paul for a quick response. When i set time_zone=>local, the perl prints correct time. [root@10.36.68.133] # ll /etc/localtime lrwxrwxrwx 1 root root 31 Oct 26 12:31 /etc/localtime -> /usr/share/zoneinfo/Asia/Manila [root@10.36.68.133] # cat test_tz.pl use DateTime; my $dt = DateTime->now(); print "The current date and time : ", $dt->strftime('%Y-%m-%d %T %z')."\n"; my $dt = DateTime->now(time_zone=>"local"); print "The current date and time : ", $dt->strftime('%Y-%m-%d %T %z')."\n"; my $date = `date`; print "$date \n"; [root@10.36.68.133] # [root@10.36.68.133] # perl test_tz.pl The current date and time : 2017-11-01 06:55:35 +0000 The current date and time : 2017-11-01 14:55:35 +0800 Wed Nov 1 14:55:35 +08 2017 [root@10.36.68.133] # Our main concern is we take epoch time and call unix localtime to translate the epoch time to local time. This is done in c which is giving wrong result now. c code looks as follows #include <stdlib.h> #include <string.h> #include <time.h> #include <syslog.h> #include <sys/time.h> /* clude defn. of gettimeofday */ #include <sys/types.h> u_int64_t sysMilliTime() { struct timeval tv; u_int64_t timestamp = 0; if ( gettimeofday(&tv, NULL) == 0) { /* seconds elapsed since jan 1, 1970 */ timestamp = (long long) tv.tv_sec; /* Convert into milli seconds */ timestamp *= 1000; timestamp += tv.tv_usec/1000; } return timestamp; } int main() { u_int64_t time = sysMilliTime(); struct tm *evTime; evTime = localtime(&time); printf("epoch:%lld, gmtoff: %ld, TZ: %s\n",time,evTime->tm_gmtoff, evTime->tm_zone); } [root@10.36.68.133] # ./a.out epoch:1509521131510, gmtoff: 0, TZ: [root@10.36.68.133] # gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3.2/configure --prefix=/opt/gcc-4.3.2 --libdir=/opt/gcc-4.3.2/lib64 --libexecdir=/opt/gcc-4.3.2/lib64 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu --enable-languages=c,c++ --disable-libstdcxx-pch Thread model: posix gcc version 4.3.2 (GCC) [root@10.36.68.133] # Please have a look and let me know your findings. Thanks, Arati ________________________________________ From: Paul Eggert <eggert@cs.ucla.edu> Sent: Wednesday, November 1, 2017 12:03 AM To: Arati Sethy Cc: Time Zone Mailing List Subject: Re: Regarding changes of time format the Philippines I am not observing either problem on Fedora 26, which currently uses tzdb 2017b and Perl 5.24.3. I ran the following shell commands. Please try them on your platform. If they work for you, can you give examples of similar shell commands that fail for you? $ TZ=Asia/Manila date Wed Nov 1 01:52:50 +08 2017 $ TZ=Asia/Manila perl -E'use DateTime; say DateTime->now(time_zone=>"local")->strftime("%Y-%m-%d %H:%M:%S %z (%Z)");' 2017-11-01 01:53:22 +0800 (+08) $ perl -E'use DateTime; say DateTime->VERSION;' 1.43 $ perl -E'use DateTime; say DateTime::TimeZone->VERSION;' 2.13 If I change "local" to "floating", I get symptoms similar to what you report: $ TZ=Asia/Manila perl -E'use DateTime; say DateTime->now(time_zone=>"floating")->strftime("%Y-%m-%d %H:%M:%S %z (%Z)");' 2017-10-31 17:57:03 +0000 (floating) However, this is what "floating" is supposed to do, and it does the same thing if TZ="America/Los_Angeles". =========================================================== Learn how to protect users, data, and applications with security engineered for the public cloud by Barracuda. http://barracuda.com DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. ===========================================================
Arati Sethy wrote:
u_int64_t time = sysMilliTime(); struct tm *evTime; evTime = localtime(&time);
Here's your problem. 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. -zefram
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".
Thank you Paul and Zefram. Well my bad i missed to update the code with seconds while calling localtime. Even after that things didn't work for me. _Code_ cat test_tz_simple.c #include <stdlib.h> #include <string.h> #include <time.h> #include <syslog.h> #include <sys/time.h> /* clude defn. of gettimeofday */ #include <sys/types.h> int main() { u_int64_t time = 0; struct timeval tv; struct tm *tm; int gmtoff, gmtoff_hr, gmtoff_min; char *gmtoff_sign; if ( gettimeofday(&tv, NULL) == 0) { time = (long long) tv.tv_sec; } *tm = localtime(&tv.tv_sec);* printf ("epoch:%lld, %lld-%02d-%02d %02d:%02d:%02d gmtoff: %ld, TZ: %s\n", time, 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); if ( tm->tm_gmtoff < 0 ) { gmtoff = (0 - tm->tm_gmtoff ); gmtoff_sign = "-"; } else { gmtoff = tm->tm_gmtoff; gmtoff_sign = "+"; } gmtoff_hr = gmtoff/3600; gmtoff_min = gmtoff/60 - gmtoff_hr*60; printf("Time: %04d-%02d-%02d %02d:%02d:%02d.%03d %s%02d%02d \n", (tm->tm_year + 1900), tm->tm_mon+1, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec, time, gmtoff_sign, gmtoff_hr, gmtoff_min); } Regarding setting TZ variable , we use customized linux platform. The way time zone is set is as follows $ cat /etc/sysconfig/clock UTC=true ARC=false ZONE=Asia/Manila $ls -ltr /etc/localtime lrwxrwxrwx 1 root root 31 Oct 26 12:31 /etc/localtime -> /usr/share/zoneinfo/Asia/Manila I tried export TZ=Asia/Manila before running a.out. But no luck. surprisingly, when i copy back 2016g version of tzdb binary, a.out gives correct result. $ cksum /usr/share/zoneinfo/Asia/Manila_2016 2614106258 319 /usr/share/zoneinfo/Asia/Manila_2016 _Output with 2016g tzdb _ $ ./a.out epoch:1509609002, 2017-11-02 15:50:02 gmtoff: 28800, TZ: PHT Time: 2017-11-02 15:50:02.1509609002 +0800 $ $ cksum /usr/share/zoneinfo/Asia/Manila_2017 2995436782 311 /usr/share/zoneinfo/Asia/Manila_2017 _Output with 2017a tzdb _ $./a.out epoch:1509608903, 2017-11-02 07:48:23 gmtoff: 0, TZ: Time: 2017-11-02 07:48:23.1509608903 +0000 In fact recompiling 2017 tzdb replacing *+08/+09 *by PH%sT for last row results in correct output. Please advice. Thanks & Regards, Arati On Thursday 02 November 2017 03:01 AM, Paul Eggert wrote:
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".
=========================================================== Learn how to protect users, data, and applications with security engineered for the public cloud by Barracuda. http://barracuda.com DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. ===========================================================
I'm afraid that I cannot reproduce the problem on Fedora 26 x86-64, built this way: git clone https://github.com/eggert/tz cd tz make TOPDIR=/tmp/tz install If I then build and run your program as follows, it is missing an #include directive but seems to run OK: $ gcc test_tz_simple.c libtz.a test_tz_simple.c: In function ‘main’: test_tz_simple.c:25:1: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration] printf ("epoch:%lld, %lld-%02d-%02d %02d:%02d:%02d gmtoff: %ld, TZ: %s\n", ^~~~~~ test_tz_simple.c:25:1: warning: incompatible implicit declaration of built-in function ‘printf’ test_tz_simple.c:25:1: note: include ‘<stdio.h>’ or provide a declaration of ‘printf’ 1015-Penguin $ TZ=Asia/Manila ./a.out epoch:1509658032, 2017-11-03 05:27:12 gmtoff: 28800, TZ: +08 Time: 2017-11-03 05:27:12.1509658032 +0800 I suggest that you run the program as follows, and compare your output to what I get: $ TZ=Asia/Manila strace -o tr ./a.out epoch:1509658190, 2017-11-03 05:29:50 gmtoff: 28800, TZ: +08 Time: 2017-11-03 05:29:50.1509658190 +0800 $ grep Manila tr open("/tmp/tz/etc/zoneinfo/Asia/Manila", O_RDONLY) = 3
Thank you Paul. Well i figure out the issue. The issue is with customized compilation of tzdb. Thanks & Regards, Arati On Friday 03 November 2017 03:19 AM, Paul Eggert wrote:
I'm afraid that I cannot reproduce the problem on Fedora 26 x86-64, built this way:
git clone https://github.com/eggert/tz cd tz make TOPDIR=/tmp/tz install
If I then build and run your program as follows, it is missing an #include directive but seems to run OK:
$ gcc test_tz_simple.c libtz.a test_tz_simple.c: In function ‘main’: test_tz_simple.c:25:1: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration] printf ("epoch:%lld, %lld-%02d-%02d %02d:%02d:%02d gmtoff: %ld, TZ: %s\n", ^~~~~~ test_tz_simple.c:25:1: warning: incompatible implicit declaration of built-in function ‘printf’ test_tz_simple.c:25:1: note: include ‘<stdio.h>’ or provide a declaration of ‘printf’ 1015-Penguin $ TZ=Asia/Manila ./a.out epoch:1509658032, 2017-11-03 05:27:12 gmtoff: 28800, TZ: +08 Time: 2017-11-03 05:27:12.1509658032 +0800
I suggest that you run the program as follows, and compare your output to what I get:
$ TZ=Asia/Manila strace -o tr ./a.out epoch:1509658190, 2017-11-03 05:29:50 gmtoff: 28800, TZ: +08 Time: 2017-11-03 05:29:50.1509658190 +0800 $ grep Manila tr open("/tmp/tz/etc/zoneinfo/Asia/Manila", O_RDONLY) = 3
=========================================================== Learn how to protect users, data, and applications with security engineered for the public cloud by Barracuda. http://barracuda.com DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. ===========================================================
participants (4)
-
Arati -
Arati Sethy
-
Paul Eggert -
Zefram