Bug 88005 - Wrong time of calendar events when using MS Exchange server
Summary: Wrong time of calendar events when using MS Exchange server
Status: RESOLVED FIXED
Alias: None
Product: korganizer
Classification: Applications
Component: exchangeplugin (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Cornelius Schumacher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-25 09:18 UTC by Andreas Heiss
Modified: 2006-03-08 07:09 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Heiss 2004-08-25 09:18:18 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    SuSE RPMs
OS:                Linux

When using a Exchange 2000 server to hold calendar events, the event times are shifted by some hours (here: 2) when accessing the exchange resource with korganizer and Outlook.
For example: Creating an event at 2pm with korganizer results in an event at 4pm when looking at the calendar with Outlook.
The timezone settings are correct on both, korganizer and Outlook. The 2 hour difference suggests that korganizer uses local time (here: Germany, European summer time) but marks the time information as UTC.
Comment 1 Roy Dragseth 2004-09-02 10:29:40 UTC
I see the same behaviour with FC2:
KDE Version 3.2.1 (KDE 3.2.3-6.5.2.kde, Fedora Core release 2 (Tettnang))
Linux (i686) release 2.6.8-1.521
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

Also, upon startup korganizer shows a time that is two hours late, I suspect it to show UTC as my zone is Europe/Oslo which is the same as Germany.  When I sync with Echange or my Palm the time indicator suddenly jumps to the correct time, but the appointments becomes two hours off what they should be.

If you look into the ics file the time fields is correct so it seems to be a time zone issue.
Comment 2 Aaron Williams 2004-11-05 03:23:38 UTC
I am also seeing timezone problems with kde 3.3.1 talking to Exchange 2003.
In my case, I found if I set my timezone to US/Pacific it does not register and tries to use UTC.  If I use PST8PDT or GMT-8 then it works for downloading.

When uploading, the meetings are appearing 8 hours ahead of when they should appear.
Comment 3 Aaron Williams 2004-11-05 06:54:11 UTC
I think I have a fix for this bug, but my fix is a bit of a hack since the timezone code doesn't seem to properly adjust it.  In exchangeupload.cpp  ExchangeUpload::startUpload dtstart and dtend need to be shifted by the appropriate amount specified by the timezone.  This should be done using zoneAsUtc, but this isn't working for me because for some reason mTimeZoneId is an empty string.  I currently adjust the time by using addSecs(tzOffset*60) and that seems to do the trick.

I will submit my patches when I get the code cleaned up a bit more.  I can now successfully add events with the correct time, but I still need to do some more testing.
Comment 4 Reinhold Kainhofer 2004-11-18 00:36:45 UTC
Actually, looking at the debug output, aaron is right. Downloading works just fine. However, when uploading the time needs to be sent in UTC. There is code in ExchangeUpload, but it doesn't have the correct timezone. Somehow the time is never adjusted to UTC, but the local time is sent as UTC time, thus the offset.

Cheers,
Reinhold
Comment 5 Reinhold Kainhofer 2004-11-18 01:58:09 UTC
CVS commit by kainhofe: 

Fix the time zone problems with uploading to an exchange server. The problem was that 1) the time zone setting was not correctly propagated to the uploader class and 2) the time zone information also wasn't used in the uploader to translate start/end times to UTC.

Both things are now fixed, and the times are correctly shifted to UTC prior to uploading.

BUG: 88005


  M +4 -2      kresources/exchange/resourceexchange.cpp   1.36
  M +4 -2      libkpimexchange/core/exchangeupload.cpp   1.14


--- kdepim/kresources/exchange/resourceexchange.cpp  #1.35:1.36
@@ -70,5 +70,6 @@ public:
 
 ResourceExchange::ResourceExchange( const KConfig *config )
-  : ResourceCalendar( config ), mCache(0), mDates(0)
+  : ResourceCalendar( config ), mCache(0), mDates(0), mClient(0), mMonitor(0), 
+    mEventDates(0), mCacheDates(0)
 {
   mLock = new KABC::LockNull( true );
@@ -117,5 +118,5 @@ bool ResourceExchange::doOpen()
   kdDebug() << "ResourceExchange::doOpen()" << endl;
 
-  mClient = new ExchangeClient( mAccount );
+  mClient = new ExchangeClient( mAccount, mTimeZoneId );
   connect( mClient, SIGNAL( downloadFinished( int, const QString & ) ),
            SLOT( slotDownloadFinished( int, const QString & ) ) );
@@ -577,4 +578,5 @@ void ResourceExchange::setTimeZoneId( co
   mTimeZoneId = tzid;
   if ( mCache ) mCache->setTimeZoneId( tzid );
+  if ( mClient ) mClient->setTimeZoneId( tzid );
 }
 

--- kdepim/libkpimexchange/core/exchangeupload.cpp  #1.13:1.14
@@ -248,4 +248,5 @@ void ExchangeUpload::startUpload( const 
   // KLUDGE: somehow we need to take the opposite of the
   // value that localUTCOffset() supplies...
+  // FIXME: What do we need that offset for anyway???
   int tzOffset = - KRFCDate::localUTCOffset(); 
   QString offsetString;
@@ -259,11 +260,12 @@ void ExchangeUpload::startUpload( const 
 
   kdDebug() << "Timezone offset: " << tzOffset << " : " << offsetString << endl;
+  kdDebug() << "ExchangeUpload::mTimeZoneId=" << mTimeZoneId << endl;
 
   addElement( doc, prop, "urn:schemas:calendar:", "dtstart", 
-      event->dtStart().toString( "yyyy-MM-ddThh:mm:ssZ" ) );
+      zoneAsUtc( event->dtStart(), mTimeZoneId ).toString( Qt::ISODate ) + "Z" );
   //    event->dtStart().toString( "yyyy-MM-ddThh:mm:ss.zzzZ" ) );
   //    2002-06-04T08:00:00.000Z" );
   addElement( doc, prop, "urn:schemas:calendar:", "dtend", 
-      event->dtEnd().toString( "yyyy-MM-ddThh:mm:ssZ" ) );
+      zoneAsUtc( event->dtEnd(), mTimeZoneId ).toString( Qt::ISODate ) + "Z" );
 #if 0
   addElement( doc, prop, "urn:schemas:calendar:", "dtstart", 


Comment 6 Reinhold Kainhofer 2004-11-18 02:09:40 UTC
CVS commit by kainhofe: 

Backport to the 3.3 Branch of fix for Bug 88005 (times were sent to the server without being shifted to UTC. This was caused by the tzid not being correctly propagated to the uploader)

CCBUG: 88005


  M +4 -2      kresources/exchange/resourceexchange.cpp   1.32.2.3
  M +4 -2      libkpimexchange/core/exchangeupload.cpp   1.13.2.1


--- kdepim/kresources/exchange/resourceexchange.cpp  #1.32.2.2:1.32.2.3
@@ -70,5 +70,6 @@ public:
 
 ResourceExchange::ResourceExchange( const KConfig *config )
-  : ResourceCalendar( config ), mCache(0), mDates(0)
+  : ResourceCalendar( config ), mClient(0), mMonitor(0), mCache(0), mDates(0), 
+    mEventDates(0), mCacheDates(0)
 {
   mLock = new KABC::LockNull( true );
@@ -117,5 +118,5 @@ bool ResourceExchange::doOpen()
   kdDebug() << "ResourceExchange::doOpen()" << endl;
 
-  mClient = new ExchangeClient( mAccount );
+  mClient = new ExchangeClient( mAccount, mTimeZoneId );
   connect( mClient, SIGNAL( downloadFinished( int, const QString & ) ),
            SLOT( slotDownloadFinished( int, const QString & ) ) );
@@ -550,4 +551,5 @@ void ResourceExchange::setTimeZoneId( co
   mTimeZoneId = tzid;
   if ( mCache ) mCache->setTimeZoneId( tzid );
+  if ( mClient ) mClient->setTimeZoneId( tzid );
 }
 

--- kdepim/libkpimexchange/core/exchangeupload.cpp  #1.13:1.13.2.1
@@ -248,4 +248,5 @@ void ExchangeUpload::startUpload( const 
   // KLUDGE: somehow we need to take the opposite of the
   // value that localUTCOffset() supplies...
+  // FIXME: What do we need that offset for anyway???
   int tzOffset = - KRFCDate::localUTCOffset(); 
   QString offsetString;
@@ -259,11 +260,12 @@ void ExchangeUpload::startUpload( const 
 
   kdDebug() << "Timezone offset: " << tzOffset << " : " << offsetString << endl;
+  kdDebug() << "ExchangeUpload::mTimeZoneId=" << mTimeZoneId << endl;
 
   addElement( doc, prop, "urn:schemas:calendar:", "dtstart", 
-      event->dtStart().toString( "yyyy-MM-ddThh:mm:ssZ" ) );
+      zoneAsUtc( event->dtStart(), mTimeZoneId ).toString( Qt::ISODate ) + "Z" );
   //    event->dtStart().toString( "yyyy-MM-ddThh:mm:ss.zzzZ" ) );
   //    2002-06-04T08:00:00.000Z" );
   addElement( doc, prop, "urn:schemas:calendar:", "dtend", 
-      event->dtEnd().toString( "yyyy-MM-ddThh:mm:ssZ" ) );
+      zoneAsUtc( event->dtEnd(), mTimeZoneId ).toString( Qt::ISODate ) + "Z" );
 #if 0
   addElement( doc, prop, "urn:schemas:calendar:", "dtstart", 


Comment 7 J. Becker 2004-11-18 02:53:25 UTC
You are the best -- Thanks!!!!!

> ------- You are receiving this mail because: -------
> You are a voter for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=88005
> reinhold kainhofer com changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |NEW
>       everconfirmed|0                           |1
>
>
>
> ------- Additional Comments From reinhold kainhofer com  2004-11-18 00:36
> -------
> Actually, looking at the debug output, aaron is right. Downloading works
> just fine. However, when uploading the time needs to be sent in UTC. There
> is code in ExchangeUpload, but it doesn't have the correct timezone.
> Somehow the time is never adjusted to UTC, but the local time is sent as
> UTC time, thus the offset.
>
> Cheers,
> Reinhold
>
>

Comment 8 Roy Dragseth 2005-12-12 10:35:31 UTC
This bug seems to have reappeared in korganizer 3.5, now the appointments are shifted with one hour again in exchange.  Further I get these messages when I upload an event to exchange:

icaltime.c:147: icaltime_from_timet() is DEPRECATED, use icaltime_from_timet_with_zone() instead

Regards,
r.
Comment 9 Craig Tsai 2006-02-15 17:21:56 UTC
I can confirm that this bug has reappeared in KDE 3.5.  In my case (US EST), all Exchange appointments are shifted +5 hours irregardless of time setting.  This does not happen to me on version 3.4.2.
Comment 10 Marc Cousin 2006-03-07 09:13:00 UTC
Same here, KDE 3.5.1, debian unstable (All appointments shifted +2)
Comment 11 Juha Tuomala 2006-03-08 07:09:12 UTC
There is a new bug 84229 for this. Please comment there.