Wrong behaviour with truncated TZif files
Hi Paul, I've built TZif files with following commands: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data # Truncate at 1 Jan 2100. ./zic -b fat -r "/@4102444800" -d ./data rearguard.zi make TZDIR="./data" all Then I've compiled attached file: g++ mktime_test.cpp localtime.o Test tries to find epoch timestamp for 2 Jul 1980 midnight at America/Los_Angeles. With a truncated TZif file it prints 331344000. With non-truncated one it prints 331372800. The latter is the right answer. Also, date command is wrong on certain time zones: make TZDIR="./data" date TZ=Antarctica/Palmer ./date -r -631152000 prints "Sat Dec 31 20:00:00 -04 1949" even though 1 Jan 1950 offset should be zero <https://github.com/eggert/tz/blob/df4699ddfc9caf6f875f1e38703dd0ef41826175/s...> . Thanks, Almaz
On 2/17/22 05:09, Almaz Mingaleev via tz wrote:
With a truncated TZif file it prints 331344000. With non-truncated one it prints 331372800. The latter is the right answer.
Thanks for reporting that. I installed the attached proposed patches; the first should fix it and the second updates a related comment. This seems to be my weekend for fixing mktime bugs, as I fixed one in glibc yesterday involving time in Indiana <https://bugs.gnu.org/48085>.
Hi Paul, Fix works for issues I've mentioned. However, I think overflow happens somewhere. Please see the attached code. I've run it in the same way as in the first message. On my workstation it prints following: sizeof time_t: 8 2120284800 -1 -218154496 -1 On Sun, 20 Feb 2022 at 21:32, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2/17/22 05:09, Almaz Mingaleev via tz wrote:
With a truncated TZif file it prints 331344000. With non-truncated one it prints 331372800. The latter is the right answer.
Thanks for reporting that. I installed the attached proposed patches; the first should fix it and the second updates a related comment.
This seems to be my weekend for fixing mktime bugs, as I fixed one in glibc yesterday involving time in Indiana <https://bugs.gnu.org/48085>.
On 5/23/22 04:48, Almaz Mingaleev wrote:
I think overflow happens somewhere. Please see the attached code.
That test doesn't look right, as each mktime call modifies its argument, polluting the next test case. Please try the attached test instead, ported to C. On my platform (Ubuntu 22.04, x86-64) this outputs: sizeof time_t: 8 2120284800 2120256000 4076812800 4076784000 which looks OK.
Yep, that was the problem. Thanks! On Mon, 23 May 2022 at 19:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 5/23/22 04:48, Almaz Mingaleev wrote:
I think overflow happens somewhere. Please see the attached code.
That test doesn't look right, as each mktime call modifies its argument, polluting the next test case. Please try the attached test instead, ported to C. On my platform (Ubuntu 22.04, x86-64) this outputs:
sizeof time_t: 8 2120284800 2120256000 4076812800 <(407)%20681-2800> 4076784000 <(407)%20678-4000>
which looks OK.
Somewhat related to truncation: settzname function [1] calls update_tzname_etc with all time types and all transitions. Shouldn't it be called only for specified local time only i.e. where ttunspecified(sp, ...) returns false? Setting any value of tzname [2] to "-00" does not look meaningful. Do I miss anything here? Thanks, Almaz [1] https://github.com/eggert/tz/blob/9fa1a5395f48fc5d563af1f58d6a8b787c27de78/l... [2] https://github.com/eggert/tz/blob/9fa1a5395f48fc5d563af1f58d6a8b787c27de78/p... On Tue, 24 May 2022 at 09:53, Almaz Mingaleev <mingaleev@google.com> wrote:
Yep, that was the problem. Thanks!
On Mon, 23 May 2022 at 19:14, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 5/23/22 04:48, Almaz Mingaleev wrote:
I think overflow happens somewhere. Please see the attached code.
That test doesn't look right, as each mktime call modifies its argument, polluting the next test case. Please try the attached test instead, ported to C. On my platform (Ubuntu 22.04, x86-64) this outputs:
sizeof time_t: 8 2120284800 2120256000 4076812800 <(407)%20681-2800> 4076784000 <(407)%20678-4000>
which looks OK.
On 5/26/22 11:23, Almaz Mingaleev wrote:
settzname function [1] calls update_tzname_etc with all time types and all transitions. Shouldn't it be called only for specified local time only i.e. where ttunspecified(sp, ...) returns false?
Yes, that sounds right. Thanks for reporting this. Proposed patch attached.
Thanks for the quick fix! On Fri, 27 May 2022 at 02:08, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 5/26/22 11:23, Almaz Mingaleev wrote:
settzname function [1] calls update_tzname_etc with all time types and all transitions. Shouldn't it be called only for specified local time only i.e. where ttunspecified(sp, ...) returns false?
Yes, that sounds right. Thanks for reporting this. Proposed patch attached.
participants (2)
-
Almaz Mingaleev -
Paul Eggert