[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19874: 25.0.50; encode-time not working as expected
From: |
Wolfgang Jenkner |
Subject: |
bug#19874: 25.0.50; encode-time not working as expected |
Date: |
Thu, 26 Feb 2015 20:00:18 +0100 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (berkeley-unix) |
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)
- bug#19874: 25.0.50; encode-time not working as expected, (continued)
bug#19874: 25.0.50; encode-time not working as expected, Ashish SHUKLA, 2015/02/26
bug#19874: 25.0.50; encode-time not working as expected,
Wolfgang Jenkner <=
- bug#19874: 25.0.50; encode-time not working as expected, Ashish SHUKLA, 2015/02/26
- bug#19874: 25.0.50; encode-time not working as expected, Wolfgang Jenkner, 2015/02/26
- bug#19874: 25.0.50; encode-time not working as expected, Ashish SHUKLA, 2015/02/26
- bug#19874: 25.0.50; encode-time not working as expected, Wolfgang Jenkner, 2015/02/26
- bug#19874: 25.0.50; encode-time not working as expected, Wolfgang Jenkner, 2015/02/26
- bug#19874: 25.0.50; encode-time not working as expected, Ashish SHUKLA, 2015/02/27
- bug#19874: 25.0.50; encode-time not working as expected, Paul Eggert, 2015/02/27
- bug#19874: 25.0.50; encode-time not working as expected, Paul Eggert, 2015/02/27
- bug#19874: 25.0.50; encode-time not working as expected, Ashish SHUKLA, 2015/02/27
bug#19874: 25.0.50; encode-time not working as expected, Paul Eggert, 2015/02/27