GNU bug report logs - #19874
25.0.50; encode-time not working as expected

Previous Next

Package: emacs;

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

From: ashish.is <at> lostca.se (Ashish SHUKLA)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19874 <at> debbugs.gnu.org
Subject: bug#19874: 25.0.50; encode-time not working as expected
Date: Thu, 26 Feb 2015 05:54:19 +0530
[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.