This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
problem about zdump
- From: "Wanghui (John)" <john dot wanghui at huawei dot com>
- To: <libc-help at sourceware dot org>
- Date: Fri, 8 Apr 2016 11:44:14 +0800
- Subject: problem about zdump
- Authentication-results: sourceware.org; auth=none
Distribution
CentOS 7.1
Version
glibc-2.17-106
zdump -v Africa/Casablanca | grep 2037
after excute the command above, it shows:
Africa/Casablanca Sun Mar 29 01:59:59 2037 UTC = Sun Mar 29 01:59:59 2037 WET isdst=0 gmtoff=0
Africa/Casablanca Sun Mar 29 02:00:00 2037 UTC = Sun Mar 29 03:00:00 2037 WEST isdst=1 gmtoff=3600
Africa/Casablanca Sun Oct 25 01:59:59 2037 UTC = Sun Oct 25 02:59:59 2037 WEST isdst=1 gmtoff=3600
Africa/Casablanca Sun Oct 25 02:00:00 2037 UTC = Sun Oct 25 02:00:00 2037 WET isdst=0 gmtoff=0
But in tzdata:
Rule Morocco 2035 only - Oct 27 3:00 0 -
Rule Morocco 2036 only - Oct 18 3:00 0 -
Rule Morocco 2037 only - Oct 10 3:00 0 -
So daylight saving time should be Oct 10th 2037 in Casablanca according to the tzfile
it might be because of thisï
else if (__builtin_expect (timer >= transitions[num_transitions - 1], 0))
{
if (__builtin_expect (tzspec == NULL, 0))
{
use_last:
i = num_transitions;
goto found;
}
/* Parse the POSIX TZ-style string. */
__tzset_parse_tz (tzspec);
/* Convert to broken down structure. If this fails do not
use the string. */
if (__builtin_expect (! __offtime (&timer, 0, tp), 0))
goto use_last;
/* Use the rules from the TZ string to compute the change. */
__tz_compute (timer, tp, 1);
after 2037-10-10 is out of the range of the setting in tzdata file, so it recalculated the daylight saving time
with previous rules, and the result become 2037-10-25
Thanks