[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19874: 25.0.50; encode-time not working as expected
From: |
Ashish SHUKLA |
Subject: |
bug#19874: 25.0.50; encode-time not working as expected |
Date: |
Thu, 26 Feb 2015 05:54:19 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (amd64-portbld-freebsd10.1) |
On Wed, 25 Feb 2015 09:41:45 -0800, Paul Eggert <eggert@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
Description: gmtime.c
signature.asc
Description: PGP signature
bug#19874: 25.0.50; encode-time not working as expected, Wolfgang Jenkner, 2015/02/26