GNU bug report logs -
#19874
25.0.50; encode-time not working as expected
Previous Next
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
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Wed, 25 Feb 2015 09:41:45 -0800, Paul Eggert <eggert <at> cs.ucla.edu> said:
| Thanks for the bug report. My guess is that there's an
| incompatibility with FreeBSD 10.1 amd64 mktime. I can't reproduce the
| problem on FreeBSD 9.1 x86.
| Please try the attached patch, just for debugging, and then run the
| following one-line shell command:
| src/emacs -Q -batch -eval '(progn (setenv "TZ" "Asia/Kolkata") (print
| (encode-time 44 42 6 15 2 2015 0 nil 0)))'
| What output do you get? Here's what I get on Fedora 21 x86-64, which seems correct:
| oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00
| 2015-02-15 06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423982564
| Assuming you get different output, can you debug Emacs with GDB to
| send us more details about what's going wrong? If not, can you give
| me access to a FreeBSD 10.1 amd64 machine like yours?
Hi,
When I looked into this before filing this bug report, from what I noticed
that it's not using libc's `mktime' function, unlike what you seem to
indicate. I'm not sure quite why it's doing that when libc provided mktime
works just fine, as evident by output of attached program:
--8<---------------cut here---------------start------------->8---
% ./gmtime
Staying at localtime zone
Time (in seconds): 1423962764
Updated environment
Switching to UTC
Time (in seconds): 1423982564
Didn't update environment
Switching to UTC+1
Time (in seconds): 1423978964
Didn't update environment
Switching to UTC+3
Time (in seconds): 1423971764
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
>>> print gmtime(1423962764)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=1, tm_min=12, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print gmtime(1423982564)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=6, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print gmtime(1423978964)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=5, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print gmtime(1423971764)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=3, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
--8<---------------cut here---------------end--------------->8---
The built-in mktime implementation (__mktime_internal) in Emacs sources don't
seem to take into account timezone offsets. I might be completely wrong here,
but the code seemed to be doing it.
I'll get back to you with the output of your command-line from patched Emacs
in few, but the results of my past investigation were handy so I've attached
them.
HTH
--
Ashish SHUKLA
“"Intellectual Property" is nowhere near as valuable as "Intellect"” ("Ion-Mihai Tetcu")
Sent from my Emacs
[gmtime.c (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 5 years and 118 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.