02-21-2012 11:00 PM - edited 02-22-2012 03:37 PM
For some reason, the email client will occasionally put the wrong time stamp on sent mail. For example, an hour or so ago I sent the Print To Go software download message. It stamped GMT (Zulu) time with a -0500 zone. Thus, apparently, it was received 5 hours before it was sent.
Here is the message with its header. I have marked the correct times in green and the client's incorrect time in red:
Delivered-To: GMX delivery to email@example.com
Received: (qmail invoked by alias); 22 Feb 2012 02:45:18 -0000
Received: from CPE940c6dfe2a95-CM000f9fa6b8b6.cpe.net.cable.roger
localhost.localdomain) [18.104.22.168] by mail.gmx.com (mp-us007) with SMTP; 21
Feb 2012 21:45:18 -0500
Content-Type: text/html; charset="utf-8"
X-Mailer: BlackBerry Email (22.214.171.12471)
Date: Wed, 22 Feb 2012 02:45:18 -0500
Subject: Download the Print To Go software
From: "Erik Wessman" <firstname.lastname@example.org>
X-Priority: 3 (normal)
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: 0 (Sender is in whitelist: email@example.com); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnTDjC+wgEZqZ
<html><head></head><body><div>Thank you for your interest in Print To Go.</=
div><div> </div><div>To download the Print To Go software to your comp=
uter, browse to www.blackberry.com/PrintToGoWindowsDownload, save the file =
to your desktop, and run the installer.</div><div>--</div><div>Enjoy!</div>=
<br><br><div id=3D"1329832952603-sig-id">Sent from my BlackBerry=C2=AE Play=
What the client appeared to have done is to use GMT time but append a local (or perhaps Waterloo/Ottawa) timezone to it. It did not use a consistent time-timezone pair as it must.
I note that where ever the device might be, a Blackberry phone seems to use Waterloo,ON time and timezone (-0500) on all messages. That is fine - or at leat it is a consistent, thus correct, set which allows the receiver to correctly assess when the email was sent.. The PlayBook client messes this up by using an inconsistent time-timezone pair.
02-22-2012 07:43 AM
02-22-2012 04:57 PM
The bug seems fairly consistent:
(a) When the compose email client was invoked from a browser (Mailto: link), the time stamp is composed of GMT time plus the local timezone.
(b) When the email client compose button was used and when my Timezone remained -0500 (Ottawa and Waterloo), the time stamp was properly paired as localtime + local timezone.
(c) When I changed my timezone to -0700 (Saskatchewan or Arizona), the mail client (whether normal or invoked from a browser) used GMT time plus -0500 (Waterloo/Ottawa) timezone.
(d) My son who is resident in Portugal (PlayBook set to timezone +0000) has his sent mail invariably time stamped incorrectly with GMT time and -0500 timezone.
This is a bug that will seriously hamper business use of the email client.
02-23-2012 09:58 AM - edited 02-23-2012 10:02 AM
I may have another, different example of this.
When I send an email from the Playbook Messages app (compose directly from the app), the date field is set to UTC but there is no time zone listed (see below). On the receiving end, this causes Thunderbird on Mac to interpret the date as UTC and apply no time zone correction. Gmail webmail displays the time correctly (presumably according to the time zone set in my gmail account) so this may be an issue with Thunderbird rather than the playbook. I am not sure if the time zone is a required part of the date field or how it should be handled by clients when it is missing.
Edit: I should add that my Playbook time is set automatically and the time zone is set to Eastern (-5).
I have sent test messages from my Blackberry Torch and they include the time zone information in the date field.
The following is the headers from a message sent from my playbook. You can see there is no time zone in the date field. I sent this email at 9:23am from EST time zone:
MIME-Version: 1.0 X-Mailer: BlackBerry Email (126.96.36.19971) From: Dan Martins <**********> X-Priority: 3 (normal) X-MSMail-Priority: Normal Importance: Normal Date: Thu, 23 Feb 2012 14:23:28
02-23-2012 11:50 AM
I just verified this - sent a message using the compose in the mail application, and grabbed the headers on their way through my outgoing mail servers (to verify that it is not an issue with the reading mail client, be it Thunderbird, Outlook or anything else).
The headers inserted on the way out are:
X-Mailer: BlackBerry Email (188.8.131.5271)
Date: Thu, 23 Feb 2012 16:37:56
The message was sent at 11:37 EST. The header as transmitted in the e-mail is missing the indication of time zone (either EST or -0500) and thus gets interpreted erroneously by the reading mail client. Mail clients vary in how they interpret the (illegal) lack of a time zone specification; some assume it is local to the reader, some assume it is UTC.
A date header with no time zone specification has been illegal since the days of RFC 822 precisely because its interpretation is ambiguous.
The Playbook mail client is clearly converting to UTC, but is then NOT indicating that the time is, in fact, UTC (illegal per the RFCs) and thus mail clients do not know how to display this.
02-23-2012 04:08 PM
02-23-2012 05:17 PM - edited 02-23-2012 05:23 PM
In Linux, Kmail adds in timezone +0000, Opera adds -0500 (my tz), and Evolution and Thunderbird add nothing but assume UTC.
RIM should fix this so that their email client conforms to the RFC and doesn't confound recipient clients. Afterall, the email client was supposedly the showpiece of Playbook's OS2!
05-19-2012 08:40 AM
Yes, "Research in Motion" SHOULD take seriously this issue...
IT WOULD impact "big time" their ability to penetrate the emerging "business" segment!
(I work for a very big multinational corporation and I got in middle of the night an urgent email with the time stamp 5 -five!- hours AFTER Eastern Time... Phone calls, confusion, frustration and a good laugh when we realized that somewhere was a "Glich"... I don't think our CEO would be pleased being put in the same situation!)
08-03-2012 01:13 PM
This error is not fixed in the Aug 2012 update.
Perhaps it is time for RIM to quietly fold its tent and just go away. The email app is a blight on Canada's reputation for engineering competence. It is sad to say that, but with 6 months to make the required simple fix to a standards violation, there is no excuse other than they just don't care about standards.