After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 215984 - Evolution forces email into wrong TZ?
Evolution forces email into wrong TZ?
Status: RESOLVED NOTXIMIAN
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other All
: Normal normal
: ---
Assigned To: Evolution Triage Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2001-11-25 02:34 UTC by paitken
Modified: 2002-04-23 18:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description paitken 2001-11-25 02:34:56 UTC
Package: Evolution
Priority: Normal
Version: 0.99.2
Synopsis: Evolution forces email into wrong TZ?
Bugzilla-Product: Evolution
Bugzilla-Component: Mailer

Description:
When I send email from Ximian Evolution 0.99.2, the TZ is set to -0500
and 5 hours are subtracted from the outgoing time.

For example, it's 0221am GMT. Here's my outgoing timestamp:

Date: 24 Nov 2001 21:21:36 -0500


When I receive messages, 5 hours are subtracted from the incoming
timestamp. For example, I can see the real email headers on my server
include:

Date: Sun, 25 Nov 2001 02:20:08 +0000

But Evolution tells me:

Date: 24 Nov 2001 21:20:08 +0000

However, I only lose 5 hours if I send a message to myself.

My shell TZ is set to TZ=GMT0BST and Evolution's calendar TZ is set to
Europe/London, although this doesn't make any difference.

I don't have this problem with other email clients, so discount my
server. Anyway, if I save a draft message before sending, I can see that
5 hours have already been subtracted as described above.



Unknown reporter: paitken@cisco.com, changed to bugbuddy-import@ximian.com.

Comment 1 paitken 2001-11-25 02:53:07 UTC
Checking my mail folders shows that email is received and stored with
the right dates, but displayed with a -0500 hours offset, so it's only
a display problem on the input side.

However, that doesn't explain why 5 hours are subtracted from outgoing
timestamps too :(
Comment 2 paitken 2001-12-08 00:11:40 UTC
This still happens in evolution 1.0

It seems the same as bug ID's 928 and 14678.
Comment 3 Luis Villa 2001-12-18 16:58:17 UTC

*** This bug has been marked as a duplicate of 214678 ***
Comment 4 Dan Winship 2001-12-18 18:02:54 UTC
(it's been fixed for 1.0.1)
Comment 5 paitken 2002-01-14 17:50:56 UTC
Sorry to say, but this issue has been made worse in 1.0.1.

I just received 1.0.1 through Ximian's redcarpet update, and this bug
is still there, but is even worse than before.

I composed a message, saved a draft and sent it. The dates on the
draft and sent message were similar to within a few seconds (as expected):

Date: 
14 Jan 2002 07:09:58 -0500

The time of sending was 17:09:58 GMT, so for some unknown reason,
Evolution has decided that my TZ is GMT-5 when it's NOT, it's just
vanilla GMT. And worse, it has then subtracted those 5 hours from the
timestamp *twice*.

On the received message, the field appears like this:

Date: 14 Jan 2002 12:09:58 -0500

So it seems to me that there are two sub problems here:

Firstly, Evolution is wrongly deciding that the TZ is GMT-5 when it's
not (and there's no way of knowing that or setting/changing it).
There's no setting on my machine to cause this and no other program
uses this TZ. I'm in the London, UK, GMT time zone.

Secondly, Evolution subtracts those 5 hours to get its internal
timestamp which is actually placed in the outgoing mail... but then it
 does this once again when displaying timestamps in the "sent" and
"drafts" folders! So the TZ offset is actually applied twice!

So for now, Evolution remains sadly unusable.
Comment 6 Jeffrey Stedfast 2002-04-23 18:53:42 UTC
well, your system is telling evolution that the timezone is -0500.

try compiling and running the following program, if you are on linux
type:

gcc -o timezone timezone.c -DHAVE_TIMEZONE

if you are on BSD, type:

gcc -o timezone timezone.c -DHAVE_TM_GMTOFF

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <stdio.h>
#include <string.h>
#include <time.h>

int main (int argc, char **argv)
{
	char tzone[10];
	struct tm *tm;
	time_t now;
	
	time (&now);
	tm = localtime (&now);
	
	strftime (tzone, 10, "%Z", tm);
	
#ifdef HAVE_TIMEZONE
	printf ("Your current timezone is %0.4d (%s)\n",
		-1 * (((timezone / 60 / 60) - daylight) * 100), tzone);
#elif HAVE_TM_GMTOFF
	printf ("Your current timezone is %0.4d (%s)\n",
		tm.tm_gmtoff, tzone);
#else
#error Neither HAVE_TIMEZONE nor HAVE_TM_GMTOFF are defined.
#endif
	
	return 0;
}


I think you'll find that your system is reporting the wrong timezone
;-)