GNU bug report logs - #19874
25.0.50; encode-time not working as expected

Previous Next

Package: emacs;

Reported by: ashish.is <at> lostca.se (Ashish SHUKLA)

Date: Sun, 15 Feb 2015 13:42:01 UTC

Severity: normal

Found in version 25.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #41 received at 19874 <at> debbugs.gnu.org (full text, mbox):

From: Wolfgang Jenkner <wjenkner <at> inode.at>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19874 <at> debbugs.gnu.org, Ashish SHUKLA <ashish.is <at> lostca.se>
Subject: Re: bug#19874: 25.0.50; encode-time not working as expected
Date: Thu, 26 Feb 2015 20:00:18 +0100
On Thu, Feb 26 2015, Paul Eggert wrote:

> On 02/26/2015 05:42 AM, Wolfgang Jenkner wrote:
>>> Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0?  You can
>>> >tell by looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.
>> What has this to do with FreeBSD?
>>
>
> If 'configure' mistakenly set APPLE_UNIVERSAL_BUILD to 1, it would
> cause 'configure' to guess that mktime was buggy, and I was worried
> that this would have caused the problem.  However, this was a red
> herring, as you've established that FreeBSD localtime and/or mktime is
> indeed buggy in this area, so 'configure' appears to be doing the
> right thing in rejecting FreeBSD mktime.

Thanks for the explanation!  However, there's no indication that mktime
is buggy (all tests pass when adjusting time_t_min, time_t_max), while
localtime (and localtime_r) certainly is.  Nevertheless, the configure
test causes mktime to be replaced but not localtime_r, which is actually
used in emacs.  If I may say so this seems a bit like pulling the wrong
tooth ;-)

> It also appears to be the case that FreeBSD 10.1's implementation of
> putenv is buggy, and that this is what is breaking Emacs's time code
> (as Emacs uses putenv to modify the TZ environment variable), but we
> haven't gotten to the bottom of that yet.  I'll try to write a little
> test program to narrow it down.

But putenv is already replaced on my 10-STABLE system (and emacs trunk):

$ nm src/emacs | grep putenv
00000000005b85a0 T rpl_putenv
0000000000527150 T xputenv

Ah, and the OP's example actually seems to give the expected result here
(my timezone is Europe/Vienna):

(encode-time 44 42 6 15 2 2015 0 nil 0)
=> (21728 16356)







This bug report was last modified 5 years and 119 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.