Summary: | %OLONGTIME template variable does not yield timezone information | ||
---|---|---|---|
Product: | [Applications] kmail2 | Reporter: | Thomas Baumgart <tbaumgart> |
Component: | composer | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aspotashev, code, kde, montel, sergiu |
Priority: | NOR | ||
Version: | 4.9.2 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/messagelib/48ecc0d629cb55e2c45d4facd62b9012db385cff | Version Fixed In: | |
Attachments: | Patch to messagelib that fixes the problem |
Description
Thomas Baumgart
2012-10-15 15:40:19 UTC
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 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 |