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

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

bug#24716: 24.3; time-subtract result is one hour off


From: Tino Calancha
Subject: bug#24716: 24.3; time-subtract result is one hour off
Date: Thu, 20 Oct 2016 04:56:31 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Friedrich Delgado <address@hidden> writes:

Thank you for your report.
I don't see nothing wrong.  See below.
> In emacs 24.3, I found that time-subtract returns a time difference
> that is one hour to large. The same appears to be valid in 25.1.
>
> Evaluate the following:
>
> (decode-time (time-subtract (encode-time 0 10 18 10 10 2016 nil 3600) 
> (encode-time 0 40 8 10 10 2016 nil 3600)))
>
> (decode-time (time-add (encode-time 0 40 8 10 10 2016 nil 3600) 
> (time-subtract (encode-time 0 10 18 10 10 2016 nil 3600) (encode-time 0 40 8 
> 10 10 2016 nil 3600))))
>
> Results are:
> (0 30 10 1 1 1970 4 nil 3600)
>
> for the first expression and
>
> (0 10 19 10 10 2016 1 t 7200)
Both results are correct.

> I'd expect a list starting with (0 30 9 ...) for the first expression
The list would start (0 30 9 ...) if the time zone correspond to
Greenwich meridian, then you would get the equivalent value:
(0 30 9 1 1 1970 4 nil 0).
> (because the duration from 8:40 in the morning to 18:10 in the evening
> is 9 hours and 30 minutes, NOT 10 hours and 30 minutes)
For time zone 3600, the origin of the time is:
(0 0 1 1 1 1970 4 nil 3600).
> and the second
> list to start with 0 10 18 (so we arrive back at the later time if we
> add the difference to the sooner time).
Indeed you have arrived back to the sooner time: it starts
(0 10 19 ... 7200)
instead of
(0 10 18 ... 3600)
just because it is expressed in your time zone, i.e., +02:00,
instead of +01:00, but it's the same absolute time.

> chipping on #emacs tells me he gets a functionally equivalent result
> on a more recent emacs version:
>
> chipping >  TauPan: what is your result for the time-subtract version? I get 
> (0 0 17 1 1 1970 4 nil 27000) on emacs 25.1.1
>
> Since (format-time-string "%H:%M" (encode-time 0 0 17 1 1 1970 4 nil
> 27000)) is "10:30" they're basically the same (wrong) result.
The value from 25.1.1
(0 0 17 1 1 1970 4 nil 27000)
is also correct: 27000 s = 7.5 h, 3600 s = 1 h
Then, to translate
(0 30 10 1 1 1970 4 nil 3600)
to 27000 time zone we need to add 7.5 - 1 = 6.5 h

10:30 + 6.5h --> 17:00

Try to pass t as third argument to display the universal time:
(format-time-string "%H:%M %z" (encode-time 0 0 17 1 1 1970 4 nil 27000) t)
=> "09:30 +0000"





reply via email to

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