Bug 366768 - Reply quote header uses UTC timestamp instead of local time zone
Summary: Reply quote header uses UTC timestamp instead of local time zone
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 5.1.3
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-14 22:31 UTC by Nick
Modified: 2017-01-11 12:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick 2016-08-14 22:31:52 UTC
When I reply to an email with a quote the header of the quote uses a UTC timestamp instead of the local time zone. In addition even though the quote timestamp says it's the local time zone it is clearly incorrect. For example, I received an email that was sent at 8:39 AM EDT (-0400). If I reply with a quote the message says "On Sunday, August 14, 2016 12:39:05 PM EDT Foo wrote:" This would be the time in UTC even though it says EDT. It is +4 hours ahead of Eastern Time.


Reproducible: Always

Steps to Reproduce:
1. Open an email
2. Reply with quote
3. Compare timestamps on the actual email to the timestamp used in the quote

Actual Results:  
Timestamp in quote is actually in UTC despite saying the local time zone (EDT in my case)

Expected Results:  
Timestamp used in quote should actually be the local time zone time.

> timedatectl 
Local time: Sun 2016-08-14 18:06:51 EDT
Universal time: Sun 2016-08-14 22:06:51 UTC
RTC time: Sun 2016-08-14 22:06:52
Time zone: America/New_York (EDT, -0400)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
Comment 1 Nick 2016-08-14 22:34:05 UTC
This is on Ubuntu 16.04
Comment 2 Matt Whitlock 2017-01-11 02:21:04 UTC
This still a problem in KMail 5.4.0.

My local time zone is America/New_York. I received a message with header "Date: Tue, 10 Jan 2017 16:51:49 +0000". When replying to this message, the template variable %OTIME expands to "4:51 PM", which is arguably okay, but the template variable %OTIMELONG expands to "4:51:49 PM EST", which is just wrong. Evidently the time zone information from the original message's Date header is being discarded, and the unqualified time is being interpreted as a local time.

Another example: original message contains "Date: Sun, 1 Jan 2017 13:31:25 -0600", but %OTIMELONG in reply expands to "1:31:25 PM EST", which again is wrong. The time zone information in the original message's Date header has been discarded, and the time has been interpreted as a local time.
Comment 3 Matt Whitlock 2017-01-11 04:12:15 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.
Comment 4 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 355195

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 5 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 355195
(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