GNU bug report logs -
#23600
25.1.50; encode-time returns wrong result
Previous Next
Reported by: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
Date: Sun, 22 May 2016 22:12:01 UTC
Severity: normal
Found in version 25.1.50
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23600 in the body.
You can then email your comments to 23600 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sun, 22 May 2016 22:12:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 22 May 2016 22:12:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When I evaluate the below code on Emacs (trunk, MSYS2), it returns
wrong result.
(list
;; local time-zone is JST-9 in my environment.
(encode-time 0 02 23 22 5 2016 nil)
(encode-time 0 02 23 22 5 2016 '(32400 "JST"))
(encode-time 0 02 23 22 5 2016 32400))
-> ((22337 48088) (22338 11352) (22338 43752))
The first element of the result depends on local time-zone. But the
second and the last element should be (22337 48088).
--
Kazuhiro Ito
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Wed, 01 Jun 2016 08:21:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 23600 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for the bug report. This appears to be due to an incompatibility between
MS-Windows and POSIX that I didn't know about. Please try the attached patch. I
have not tested or installed this (I don't use MS-Windows).
[0001-Port-angle-bracket-TZ-settings-to-MS-Windows.patch (text/x-diff, attachment)]
Added tag(s) patch.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Wed, 01 Jun 2016 08:22:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Thu, 02 Jun 2016 01:55:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 23600 <at> debbugs.gnu.org (full text, mbox):
> Thanks for the bug report. This appears to be due to an incompatibility
> between MS-Windows and POSIX that I didn't know about. Please try the
> attached patch. I have not tested or installed this (I don't use
> MS-Windows).
Thank you for the fix. The problem I showed in the bug report seems
to be resolved. But there still be a problem related timezone (I
dont' know whether it is the same problem). With your patch, the
below code returns unexpected result.
(list (progn (set-time-zone-rule 0)
(current-time-zone))
(progn (set-time-zone-rule "JST-9")
(current-time-zone))
(progn (set-time-zone-rule "<JST>-9")
(current-time-zone)))
-> ((0 "ZZZ") (0 "ZZZ") (32400 "JST"))
I want it to return '((0 "ZZZ") (32400 "JST") (32400 "JST"))'.
--
Kazuhiro Ito
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Thu, 02 Jun 2016 06:39:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 23600 <at> debbugs.gnu.org (full text, mbox):
Kazuhiro Ito wrote:
> Thank you for the fix. The problem I showed in the bug report seems
> to be resolved.
Thanks, I installed the fix in master.
> But there still be a problem related timezone (I
> dont' know whether it is the same problem). With your patch, the
> below code returns unexpected result.
>
> (list (progn (set-time-zone-rule 0)
> (current-time-zone))
> (progn (set-time-zone-rule "JST-9")
> (current-time-zone))
> (progn (set-time-zone-rule "<JST>-9")
> (current-time-zone)))
>
> -> ((0 "ZZZ") (0 "ZZZ") (32400 "JST"))
>
> I want it to return '((0 "ZZZ") (32400 "JST") (32400 "JST"))'.
Yes, that's the correct result and it's what I observe on Ubuntu 16.04 x86-64. I
don't offhand see how the just-installed patch would cause the wrong answer for
the "JST-9" case, as the patch cannot make a difference unless TZ's value starts
with "<".
Do you see the same (wrong) behavior for "JST-9" in the emacs-25 branch? In
Emacs 24.5?
Removed tag(s) patch.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Thu, 02 Jun 2016 14:53:01 GMT)
Full text and
rfc822 format available.
Added tag(s) moreinfo.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Thu, 02 Jun 2016 14:53:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sat, 04 Jun 2016 15:52:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 23600 <at> debbugs.gnu.org (full text, mbox):
> Cc: 23600 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 1 Jun 2016 01:19:50 -0700
>
> + if (strncmp (str, "TZ=<", 4) == 0)
> + {
> + /* MS-Windows does not support POSIX.1-2001 angle-bracket TZ
> + abbreviation syntax. Convert to POSIX.1-1988 syntax if possible,
> + and to the undocumented placeholder "ZZZ" otherwise. */
> + bool supported_abbr = true;
> + for (char *p = str + 4; *p; p++)
> + {
> + if (('0' <= *p && *p <= '9') || *p == '-' || *p == '+')
> + supported_abbr = false;
> + else if (*p == '>')
> + {
> + ptrdiff_t abbrlen;
> + if (supported_abbr)
> + {
> + abbrlen = p - (str + 4);
> + memmove (str + 3, str + 4, abbrlen);
> + }
> + else
> + {
> + abbrlen = 3;
> + memset (str + 3, 'Z', abbrlen);
> + }
> + memmove (str + 3 + abbrlen, p + 1, strlen (p));
> + break;
> + }
Do callers of putenv expect the argument to be destroyed?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sat, 04 Jun 2016 17:16:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 23600 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Do callers of putenv expect the argument to be destroyed?
Yes and no. POSIX says that the environment can be modified in-place, so a
caller of putenv (S) should be prepared for *S to be modified (which is what I
assume you mean by "destroyed") because the string will be put into the
environment. Also, POSIX allows putenv to modify *S, as S is of type char * and
there is no prohibition in the standard against putenv modifying the pointed-to
storage. That being said, I don't know of any POSIXish implementation of putenv
(S) that modifies *S and I doubt whether any mainstream implementation would do
that.
Although the code you mention is stretching things a bit, it's not stretching
them beyond recognition: the intent of putenv ("TZ=<JST>-9") is not really "set
the 'TZ' value to the byte-string '<JST>-9' in the environment array", it's more
"set the time zone to 9 hours ahead of UTC and with abbreviation 'JST'", and on
MS-Windows the code implements this intent more faithfully than doing nothing would.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sat, 04 Jun 2016 17:38:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 23600 <at> debbugs.gnu.org (full text, mbox):
> Cc: kzhr <at> d1.dion.ne.jp, 23600 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 4 Jun 2016 10:15:04 -0700
>
> > Do callers of putenv expect the argument to be destroyed?
>
> Yes and no. POSIX says that the environment can be modified in-place, so a
> caller of putenv (S) should be prepared for *S to be modified (which is what I
> assume you mean by "destroyed") because the string will be put into the
> environment. Also, POSIX allows putenv to modify *S, as S is of type char * and
> there is no prohibition in the standard against putenv modifying the pointed-to
> storage. That being said, I don't know of any POSIXish implementation of putenv
> (S) that modifies *S and I doubt whether any mainstream implementation would do
> that.
Right, that's what I thought.
> Although the code you mention is stretching things a bit, it's not stretching
> them beyond recognition: the intent of putenv ("TZ=<JST>-9") is not really "set
> the 'TZ' value to the byte-string '<JST>-9' in the environment array", it's more
> "set the time zone to 9 hours ahead of UTC and with abbreviation 'JST'", and on
> MS-Windows the code implements this intent more faithfully than doing nothing would.
I think it would be cleaner if we copied the string before modifying
it. I will do that when I have time.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sat, 04 Jun 2016 22:19:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 23600 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> I think it would be cleaner if we copied the string before modifying
> it.
Other parts of Emacs modify the string in place and expect the modifications to
affect the time zone setting, so in general it won't work to copy the string,
modify the copy, and pass the copy's address to putenv.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sun, 05 Jun 2016 02:48:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 23600 <at> debbugs.gnu.org (full text, mbox):
> Cc: kzhr <at> d1.dion.ne.jp, 23600 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 4 Jun 2016 15:18:43 -0700
>
> Eli Zaretskii wrote:
> > I think it would be cleaner if we copied the string before modifying
> > it.
>
> Other parts of Emacs modify the string in place and expect the modifications to
> affect the time zone setting, so in general it won't work to copy the string,
> modify the copy, and pass the copy's address to putenv.
Too bad.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sun, 05 Jun 2016 11:09:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 23600 <at> debbugs.gnu.org (full text, mbox):
> > Thank you for the fix. The problem I showed in the bug report seems
> > to be resolved.
> Thanks, I installed the fix in master.
Thank you.
> > But there still be a problem related timezone (I
> > dont' know whether it is the same problem). With your patch, the
> > below code returns unexpected result.
> >
> > (list (progn (set-time-zone-rule 0)
> > (current-time-zone))
> > (progn (set-time-zone-rule "JST-9")
> > (current-time-zone))
> > (progn (set-time-zone-rule "<JST>-9")
> > (current-time-zone)))
> >
> > -> ((0 "ZZZ") (0 "ZZZ") (32400 "JST"))
> >
> > I want it to return '((0 "ZZZ") (32400 "JST") (32400 "JST"))'.
> Yes, that's the correct result and it's what I observe on Ubuntu 16.04
> x86-64. I don't offhand see how the just-installed patch would cause the
> wrong answer for the "JST-9" case, as the patch cannot make a difference
> unless TZ's value starts with "<".
>
> Do you see the same (wrong) behavior for "JST-9" in the emacs-25 branch?
> In Emacs 24.5?
Emacs 24.5 can treat "JST-9" correctly but not for "<JST-9>",
emacs-25 shows the same result as trunk.
(list
(progn (set-time-zone-rule "<AAA>-1")
(current-time-zone))
(progn (set-time-zone-rule t)
(current-time-zone))
(progn (set-time-zone-rule "BBB-2")
(current-time-zone))
(progn (set-time-zone-rule 36000)
(current-time-zone))
(progn (set-time-zone-rule "<JST>-9")
(current-time-zone)))
emacs-25 branch
-> ((32400 "JST") (0 "GMT") (32400 "JST") (32400 "JST") (32400 "JST"))
emacs-25 branch with sys_putenv patch and trunk
-> ((3600 "AAA") (0 "GMT") (3600 "AAA") (36000 "ZZZ") (32400 "JST"))
(list (progn (set-time-zone-rule "GMT0")
(current-time-zone))
(progn (set-time-zone-rule "BBB-2")
(current-time-zone))
(progn (set-time-zone-rule "<JST>-9")
(current-time-zone)))
24.5 pre-built binary
-> ((0 "GMT") (7200 "BBB") (3600 "T>-"))
--
Kazuhiro Ito
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sun, 05 Jun 2016 15:20:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 23600 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 05 Jun 2016 05:47:27 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: kzhr <at> d1.dion.ne.jp, 23600 <at> debbugs.gnu.org
>
> > Cc: kzhr <at> d1.dion.ne.jp, 23600 <at> debbugs.gnu.org
> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Sat, 4 Jun 2016 15:18:43 -0700
> >
> > Eli Zaretskii wrote:
> > > I think it would be cleaner if we copied the string before modifying
> > > it.
> >
> > Other parts of Emacs modify the string in place and expect the modifications to
> > affect the time zone setting, so in general it won't work to copy the string,
> > modify the copy, and pass the copy's address to putenv.
>
> Too bad.
Actually, could you point me to those places? Because if the code
which expects that is not already ifdef'ed out/around for Windows,
it's a problem waiting to be discovered, since MS _putenv accepts a
'const char *' argument, and my references indicate that the
implementation indeed copies the input string. So those other parts
of the code expect something that cannot work on Windows.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Mon, 06 Jun 2016 01:49:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 23600 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Actually, could you point me to those places?
It's emacs_setenv_TZ, in editfns.c. Ah, now I see that there's an ifdef
WINDOWSNT there that sidesteps the issue on MS-Windows, so you should be OK.
Removed tag(s) moreinfo.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Wed, 08 Jun 2016 20:07:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Sun, 12 Jun 2016 10:46:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 23600 <at> debbugs.gnu.org (full text, mbox):
I noticed that calling format-time-string (or encode-time) with
time-zone string fixes the problem. But I can't see why.
(list
(progn (set-time-zone-rule "<AAA>-1")
(current-time-zone))
(progn (set-time-zone-rule "BBB-2")
(current-time-zone))
(progn (format-time-string "" nil "UTC0")
(current-time-zone)))
-> ((3600 "AAA") (3600 "AAA") (7200 "BBB"))
--
Kazuhiro Ito
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Mon, 13 Jun 2016 21:56:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 23600 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/12/2016 03:45 AM, Kazuhiro Ito wrote:
> I noticed that calling format-time-string (or encode-time) with
> time-zone string fixes the problem. But I can't see why.
I think I see the problem, at least on GNU/Linux: localtime_r needs
someone else to call tzset. I installed the attached patch into the
master branch, to do that.
[0001-Call-tzset-after-setting-TZ.patch (application/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23600
; Package
emacs
.
(Tue, 14 Jun 2016 14:07:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 23600 <at> debbugs.gnu.org (full text, mbox):
> > I noticed that calling format-time-string (or encode-time) with
> > time-zone string fixes the problem. But I can't see why.
>
> I think I see the problem, at least on GNU/Linux: localtime_r needs
> someone else to call tzset. I installed the attached patch into the
> master branch, to do that.
I confirmed the patch resolves the problem. Thank you for the fix.
--
Kazuhiro Ito
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Tue, 14 Jun 2016 14:41:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
:
bug acknowledged by developer.
(Tue, 14 Jun 2016 14:41:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 23600-done <at> debbugs.gnu.org (full text, mbox):
Thanks for checking; closing the bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 13 Jul 2016 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 34 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.