bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner <wjenkner@inode.at>]

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)