Using the following line in the reply-to template On %ODATE %OTIMELONG you wrote: yields the following results with the resp. date header found in the original mail presented on the line underneath: On Monday 15 October 2012 13:34:36 you wrote: Date: Mon, 15 Oct 2012 13:34:36 +0000 On Monday 15 October 2012 15:34:56 you wrote: Date: Mon, 15 Oct 2012 15:34:56 +0200 These are taken from two different mails which I received and that are sent just 20 seconds apart. Replying to them shows a two hour difference though and no timezone information is given. I would expect that the first one above would show 15:34:36 as time which is my local time. I also tried the other template vars %OLONGTIMEEN and %OTIME but that does not make a difference.
could you paste header from theses two emails please ?
The above 'Date:' lines are copied directly from the mail's headers. Do you need more? Which ones?
I don't understand why there is this bug. If there is a bug it's in kdelibs. We use kdelibs code to return date
I can confirm this behaviour on Kontact 4.14. The message headers contain the time in UTC (for example "Date: Fri, 13 Jun 2014 07:40:23 +0000") but I'm in another time zone (+3000). The person that sent the mail is in the same time zone as me. I'd like to have %OTIME taking into account my tome zone, or if that is not possible, then at least a new command (something like "%OTIMELOCALTZ") that displays the time of the original message but converted to the local time zone. This look more like a wish, but it causes inconsistencies in the Kontact interface: I see "10:40:23" as the time when the email was sent to me, but when replying to the same email I get %OTIME inserted as 07:40:23. It also confuses the receiving party, because %OTIME does not print the time zone near the time it generates.
Correction: Kontact 4.13
See also https://bugs.kde.org/show_bug.cgi?id=355195
Created attachment 103342 [details] Patch to messagelib that fixes the problem QDateTime::time() returns a QTime, which conveys no time zone information. QLocale::toString(const QTime &, QLocale::FormatType) then assumes that the passed QTime is a local time. This causes a problem when processing a template in that the time zone information of the Date header in the original message is ignored, and the time part is then reinterpreted as a local time, which is incorrect. Example illustrating the problem: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 1:31:25 PM EST QLocale apparently offers no method to format a QTime with a specific QTimeZone, so the best that can be done is to convert the QDateTime of the original message into a local time by calling QDateTime::toLocalTime(). After applying this fix, the above example becomes: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 2:31:25 PM EST
Git commit 2fafabbf7563c44d75f9e9b06b5314ef3dce4763 by Montel Laurent. Committed on 11/01/2017 at 12:27. Pushed by mlaurent into branch 'master'. Apply patch from Matt Whitlock + add autotest to validate it QDateTime::time() returns a QTime, which conveys no time zone information. QLocale::toString(const QTime &, QLocale::FormatType) then assumes that the passed QTime is a local time. This causes a problem when processing a template in that the time zone information of the Date header in the original message is ignored, and the time part is then reinterpreted as a local time, which is incorrect. Example illustrating the problem: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 1:31:25 PM EST QLocale apparently offers no method to format a QTime with a specific QTimeZone, so the best that can be done is to convert the QDateTime of the original message into a local time by calling QDateTime::toLocalTime(). After applying this fix, the above example becomes: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 2:31:25 PM EST Related: bug 355195, bug 366768 M +52 -14 templateparser/autotests/templateparsertest.cpp M +3 -0 templateparser/autotests/templateparsertest.h M +8 -8 templateparser/src/templateparser.cpp https://commits.kde.org/messagelib/2fafabbf7563c44d75f9e9b06b5314ef3dce4763
Git commit 48ecc0d629cb55e2c45d4facd62b9012db385cff by Montel Laurent. Committed on 11/01/2017 at 12:29. Pushed by mlaurent into branch 'Applications/16.12'. Apply patch from Matt Whitlock + add autotest to validate it QDateTime::time() returns a QTime, which conveys no time zone information. QLocale::toString(const QTime &, QLocale::FormatType) then assumes that the passed QTime is a local time. This causes a problem when processing a template in that the time zone information of the Date header in the original message is ignored, and the time part is then reinterpreted as a local time, which is incorrect. Example illustrating the problem: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 1:31:25 PM EST QLocale apparently offers no method to format a QTime with a specific QTimeZone, so the best that can be done is to convert the QDateTime of the original message into a local time by calling QDateTime::toLocalTime(). After applying this fix, the above example becomes: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 2:31:25 PM EST Related: bug 355195, bug 366768 (cherry picked from commit 2fafabbf7563c44d75f9e9b06b5314ef3dce4763) M +52 -14 templateparser/autotests/templateparsertest.cpp M +3 -0 templateparser/autotests/templateparsertest.h M +8 -8 templateparser/src/templateparser.cpp https://commits.kde.org/messagelib/48ecc0d629cb55e2c45d4facd62b9012db385cff