bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: bug#19874: 25.0.50; encode-time not working as expected
Date: Thu, 26 Feb 2015 22:31:41 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Wolfgang Jenkner wrote:

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 ;-)

I suppose we could make Gnulib smarter, so that it replaces some other function if it finds a particular bug in mktime, a bug that can be chalked up to localtime_r etc. However, the current approach is simpler to maintain and shouldn't hurt anything. Ashish's problem seems not to be in mktime at all (nor in its replacement).

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

Yes, and that's because FreeBSD putenv is incompatible with GNU putenv; in GNU systems, putenv ("xxx") is equivalent to unsetenv ("xxx") but FreeBSD doesn't support this extension to POSIX. I don't know whether Emacs needs this extension, but it shouldn't hurt to have it.

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

Yes. I can't reproduce the problem either. I finally got around to building a VM running FreeBSD 10.1 amd64, and I cannot reproduce the bug, even when /etc/localtime is a copy of /usr/share/zoneinfo/Asia/Kolkata and TZ is initially unset. However, I am running it in a text window, not under Gtk3.

Perhaps Gtk3 is in some way interfering with Emacs's putenv substitute.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]