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

[Friedrich Delgado]

Ah, thanks for explaining this!

I had the suspicion that I might have overlooked something, that's why
I tried to get feedback on #emacs first before submitting this as a
bug (unfortunately there weren't many people available at that time).

I simply didn't think of checking the timezone and of course I didn't
read the full documentation of these functions. :)

Sorry for the noise!

Kind regards
     Friedel

Tino Calancha: %<--- %<--- %<--- %<--- %<---
> Friedrich Delgado <delgado@dfn-cert.de> 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"
%<--- %<--- %<--- %<--- %<--- %<---

-- 
Dipl.-Inform Friedrich Delgado             (Projekt- und Entwicklungsteam)

DFN-CERT Services GmbH, https://www.dfn-cert.de/
Sitz/Register: Hamburg,  AG Hamburg,  HRB 88805,  Ust-IdNr.: DE 232129737
Sachsenstraße 5, 20097 Hamburg/Germany,  CEO: Dr. Klaus-Peter Kossakowski