When forwarding or replying to a message, the time zone information of the old message is just thrown away. When forwarding or replying to a message, a customizable standard template is used. See: Settings => Configure KMail => Composer => Standard Templates For those you can use time and date values of the original mail such as: %ODATE (Date) %ODATEEN (Date in C Locale) %ODATESHORT (Date in Short format) %OTIME (Time) %OTIMEEN (Time in C Locale) %OTIMELONG (Time in Long Format) To get something like: On %ODATEEN, %OTIMELONGEN, %OFROMNAME wrote: On a concrete mail this will expand to something like: On Friday 02 November 2015, 09:17:44, Alice wrote: Nevertheless Alice original mail said: Date: Fri, 02 Nov 2015 09:17:44 +0800 So this is some very different time than 09:17:44 UTC for example. So those %... variables should either always contains the time zone (e.g. +0800) or there should be an additional variable for this. Alternatively there should be variables offering a recalculated time, based on the local time of the forwarding / replying persons computer. Maybe the difference between %OTIME and %OTIMEEN was intended for this. But actually I can't find any difference in the behaviour of these both variables. Maybe broken!?!? Additionally, a localized/non-localized version of the %OTIMELONG variable would be needed. I like the idea to recalculate to the forwarders/replyers local time and add the time zone string, e.g. +0800 It's the same what KMail does when showing the Date of a normal email when reading. And don't forget, the %ODATE... variables are probably affected too (date-borders). Reproducible: Always
I too ran accross this bug. These bugs also seem to suffer from the same problem: https://bugs.kde.org/show_bug.cgi?id=341909 https://bugs.kde.org/show_bug.cgi?id=308444 Steps to reproduce: 1. Find a mail in your inbox, that has a "Date:" header different from your Local Timezone. Local Timezone: CET Mail with header "Date: Sun, 27 Dec 2015 15:20:55 -0800" 2. Create custom template for reply (or edit a default one): TIME %TIME DATE %DATE DATEEN %DATEEN TIMELONG %TIMELONG TIMELONGEN %TIMELONGEN OHEADER: %OHEADER="Date" OTIME %OTIME ODATE %ODATE ODATEEN %ODATEEN OTIMELONG %OTIMELONG OTIMELONGEN %OTIMELONGEN 3. Reply to the mail with your custom template. Actual Results: TIME 00:36 DATE Dienstag, 5. Januar 2016 DATEEN Tuesday, 5 January 2016 TIMELONG 00:36:43 CET TIMELONGEN 00:36:43 CET OHEADER: Sun, 27 Dec 2015 15:20:55 -0800 OTIME 15:20 ODATE Sonntag, 27. Dezember 2015 ODATEEN Sunday, 27 December 2015 OTIMELONG 15:20:55 CET OTIMELONGEN 15:20:55 CET Expected Results (CET is UTC+1): TIME 00:36 DATE Dienstag, 5. Januar 2016 DATEEN Tuesday, 5 January 2016 TIMELONG 00:36:43 CET TIMELONGEN 00:36:43 CET OHEADER: Sun, 27 Dec 2015 15:20:55 -0800 OTIME 00:20 ODATE Montag, 28. Dezember 2015 ODATEEN Monday, 28 December 2015 OTIMELONG 00:20:55 CET OTIMELONGEN 00:20:55 CET Also, there should be a template pattern family like %OTIMELONGUTC: OHEADER: Sun, 27 Dec 2015 15:20:55 -0800 OTIMEUTC: 23:20 ODATEUTC Sunday, 27 December 2015 OTIMELONGUTC 23:20:55 UTC The datetime is corretly displayed in the message list view. And the fancy message header in the message view. I run Archlinux KMail Version 5.1 KDE Frameworks 5.18-0 Qt 5.5.1
Thanks for the comment Ben! Actually I'd prefer to see the timezone offset (e.g. +0800). Especially because I'm mailing with people in different timezones, this seems to be the better way instead of recalculating everything to my local timezone without any attached timezone information.
(In reply to kolAflash from comment #2) > Actually I'd prefer to see the timezone offset (e.g. +0800). Especially > because I'm mailing with people in different timezones > this seems to be the better way instead of recalculating everything to my local timezone without > any attached timezone information. As i understand from reading the source in templateparser.cpp this is actually the desired behavior of the %OTIME and %OTIMELONG pattern. But somehow the timezone information is passed either missing or passed incorrectly. I do not see whether this is a problem with the KMime library, templateparser or somewhere else in the kdepim infrastructure. Maybe it's Akonadi while providing the message? Someone with a working debug environment should look into it. I currently do not have such a environment running.
I have produced a patch, attached to Bug 308444, that fixes the problem of time zone information being discarded when processing these template variables. Note: My patch does not address the reporter's request for the introduction of UTC-forced template variables.
I tried to create autotest to reproduce this bug. No success yet so I can't test for the moment this patch. Regards
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 308444, 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 308444, 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