Bug 355195

Summary:	date and time are ambiguous when replying to and forwarding messages (no timezone information)
Product:	[Applications] kmail2	Reporter:	kolAflash <kolAflash>
Component:	composer	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	aspotashev, code, kde, montel
Priority:	NOR
Version:	4.14.7
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://commits.kde.org/messagelib/48ecc0d629cb55e2c45d4facd62b9012db385cff	Version Fixed In:
Sentry Crash Report:

Description kolAflash 2015-11-11 15:55:13 UTC

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

Comment 1 Ben 2016-01-05 00:00:49 UTC

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

Comment 2 kolAflash 2016-01-08 20:51:03 UTC

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.

Comment 3 Ben 2016-01-09 15:18:44 UTC

(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.

Comment 4 Matt Whitlock 2017-01-11 04:09:19 UTC

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.

Comment 5 Laurent Montel 2017-01-11 07:01:00 UTC

I tried to create autotest to reproduce this bug.
No success yet so I can't test for the moment this patch.

Regards

Comment 6 Laurent Montel 2017-01-11 12:28:27 UTC

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

Comment 7 Laurent Montel 2017-01-11 12:29:23 UTC

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