Version: (using KDE KDE 3.2.3) Installed from: RedHat RPMs OS: Linux This bug looks like bugs #40193 and #82209, and I can confirm again that this bug still exists. For some unknown reason, meaning I have made no change to my machine, I open Korganizer today and all my appointments have shifted back in time 6 hours. Since this bug has been causing me a problem in Korganizer for all versions of KDE back to 3.0, I though I had figured out that the correct way to avoid the bug was to never set the timezone in the Korganiser time zone config area, but to just set the zone on the panel clock. I select North America, and then Korganiser works, or did up until today. The best (or worst part) is that I share two calendars across my LAN, and now the one machine that was having trouble has paased the problem on to the other machine, which wasn't having problems, now all my calendar events on both machines are 6 hours early. By the way, on one machine I have FC1 standard RPMS, on the other machine I have kde-redhat rpms, and on a previous version of kde that had the same problem, I was using a stock Debian kde. This bug is a killer because it is causing data corruption. Once the data has shifted, I can't get it to go forward 6 hours.
I created a new calendar file on each of my machines, the desktop and the laptop. I entered an event on the laptop, form 9:30 PM EST to 10 PM EST, and when I share the calendar to the desktop, it shows up as 10:30 PM to 11:00 PM. So even though both machines are set the same as far as time zone goes, they show differing event times when the calendars are shared.
On Wednesday, 30. June 2004 15:46, mail4xxxx@imap.cc wrote: > ------- I created a new calendar file on each of my machines, the desktop > and the laptop. I entered an event on the laptop, form 9:30 PM EST to 10 PM > EST, and when I share the calendar to the desktop, it shows up as 10:30 PM > to 11:00 PM. So even though both machines are set the same as far as time > zone goes, they show differing event times when the calendars are shared. Which timezones did you specify in korganizer on both machines? Have you also set them to your actual timezone? Reinhold -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA4sZ/TqjEwhXvPN0RAgj2AJ9ugpXr4MfRgdrkvccFKlAkewocfgCgiv+/ vlohEv3TVLSN9KIoum5BOyU= =Txfa -----END PGP SIGNATURE-----
Initially I would only set United States of America in the Date and Time Format option on the K Clock. I would not set the timezone in Korganizer. In previous versions of Korganizer (I can't remember which, maybe in late 2.x), I experienced a constant shifting of event times, meaning every time I opened Korganizer the events would shift back 5 hours. It seemed to be related to setting a timezone in Korganizer, so I just stopped doing it and the data seemed to stablize. Two days ago, when this new time shifting happened, I had still not set a timezone in Korganizer, only the Date and Time Format option in Clock. I have looked at korganizerrc, and in my typical configuration of no timezone selected, under the [Time and Date] section it would say TimeZoneId=EDT. I am in the America/New York time zone. Also, looking at the data in my calendar file, the DTSTART and DTEND lines are in EDT, for example, DTSTART:20020305T184500Z was an event that actually did start at 6:45 PM in my timezone. I've created new calendar files, and they seem to store the data in GMT, and then Korganizer adjusts the time based on the selected Time Zone.
More info; On my desktop machine, which is FC2 stock KDE, I create a new calendar file, with the timezone in Korganizer set to America/New York. I create an event that goes from 11:30 AM to 6:00 PM, and these are the DTSTART and the DTEND fields: DTSTART:20040628T153000Z DTEND:20040628T220000Z. Seems that the GMT-5 plus 1 for DST (daylight savings time) formula works. On my laptop, I create a new calendar file, with the same timezone settings as the desktop. The laptop is FC1 with kde-redhat 3.2.3. I create an event that goes from 3:00 PM to 2:15 AM the next day, these are the DTSTART and DTEND fields: DTSTART:20040630T190000Z DTEND:20040701T061500Z. Once again, the formula above works. The problem is that my original calendar file has date stamps as mentioned in the previous post, that is, not in GMT, but in GMT-5 plus 1. I don't know how this file had its time stamps saved in non-GMT. How or why a couple of days ago Korganizer decided it was going to start observing a timezone that I didn't select I don't know either. At no point in time was I required to select a timezone, like in Evolution's setup. If Korganizer saves data based on a timezone selection, and that data could be rendered almost useless if a timezone isn't selected at the creation of a new calendar file, shouldn't there be a REQUIRED selection of timezone? And what happens if one machine has not selected a timezone shares a calendar with a machine that has selected a timeone?
Now I enter a new event in a new calendar file with no timezone selected in Korganizer, close Korganizer, reopen, and the event is now five hours earlier. Can reproduce every time. Where is Korganizer getting a -5 hour offset if I don't have a timezone selected? Why is it moving the event?
Hello? Anyone there?
I have the same problem, basically. Korganizer shifts events by 8 hours forward, every time I reload (which is really frustrating after I spend an hour correcting everything!)
*** Bug 82209 has been marked as a duplicate of this bug. ***
I have had this problem in v3.3.1. It went away after I set my system clock from UTC to local time, then set the time zone in Korganizer to the correct time zone. The shift was exactly the difference between UTC and the local time zone, which is what made me suspicious. It appears that somewhere in Korganizer it uses a time or time zone from the system clock to compute the incoming appointment times. I tried resetting the system clock back to UTC but now have been unable to reproduce the problem, which occurred when I copied a calendar file to my work machine, which was set with the system clock to local time, and the Korganizer time set to the correct time zone. I'm wondering if some deeper configuration setting was done that I've not noticed. Either way, it might be good for the default setting on Korganizer to be the local time zone right from the start, rather than a blank time zone.
I just saw this bug in korganizer 3.3.2 (KDE 3.3.2 under Gentoo Linux). When we went to daylight saving time in Denmark, all my appointments were shiftet forward in time, some of them by one hour, some by two hours. Fortunately, I only recently started using korganizer, so I still had (almost) everything in my paper calendar. I will continue to use a paper backup :-( My computer keeps time as local time. My machine is dual boot, so I booted into Windows and allowed it to set the hardware clock before booting into Linux. I think it is the timezone change that caused the trouble. I do not set the timezone in korganizer.
I just saw that the original bug mentions the platform as RedHat RPM. I saw the problem with Gentoo Linux, so it is probably not platform specific.
I've got this in Gentoo too, with KDE 3.4. In my case, no matter what I do, I can't get Korganizer to stop using UTC for everything --- so when I open a calendar file which was written by KOrganizer on another machine where things worked correctly, all the appointments are shifted by 5 hours, which is the difference between my time zone and UTC. (Looking at the .ics file verifies that the old machine was doing it right and this machine is doing it wrong.)
*** This bug has been confirmed by popular vote. ***
At least for me (and for some other Gentoo users as well) this bug turned out to be related to a specific version of glibc -- upgrading/downgrading glibc made it go away. It has been discussed on the Gentoo forums at http://forums.gentoo.org/viewtopic-t-289746-postdays-0-postorder-asc-start-25.html
*** Bug 93308 has been marked as a duplicate of this bug. ***
I just upgraded from KDE 3.3.2 to KDE 3.4.1. All my appointments were moved by two hours. It is the second time that this happens, and I am beginning to doubt the wisdom of using korganizer for something as important as my calendar.
I have recently upgraded from KDE 3.4.1 tp 3.4.2 and one of my users has had all of her RECURREING events shifted 3 hours back. System clock is set to local time as well as all other regional settings (which is EST, UTC -5) ...so the shift of -3 hours doesn't make much sense for the moment. This behaviour seems to happen at each KDE upgrade and has become more than a nuisance. I will provide any additionnal info upon request.
In korganizer, I setup and exchange 2000 resource. When I retrieve the exchange details (calender info). It adds it to my address book two hours early. (Which is incidentally GMT). It appears to be looking for /usr/share/zoneinfo/SAST which is not a timezone and should instead be looking for /usr/share/zoneinfo/Africa/Johannesburg. The work around is to symlink it back to /usr/share/zoneinfo/SAST.
How did you determine that it was looking for SAST? I created that symlink but the problem persists.
I strace'd korganizer at startup for another reason, and noticed it trying to open /usr/share/timezone/SAST, when I was aware that the correct timezone file for SAST was in fact Africa/Johannesburg (but ... of course that will only be the case for us South Africans). For the OP, symlinking America/New\ York to EDT should workaround this bug. BTW, I encounter this as well, running on multiple versions of Mandriva (2005LE, 2006, cooker).
I just upgraded from KDE 3.4.1 to KDE 3.5 and all my appointments were moved by 3! hours. Meeting is at 10 in Outlook/Exchange. If I download this to Korganizer, the meeting will show up at 07.00 in KO. My hardware clock is set to UTC and my time-zone is EET (same as Helsinki) I need to have my downloaded meetings with correct time. Any idea what to do? I did change the hardware clock to EET etc but this had no effect.
I just upgraded to KDE 3.5 from KDE 3.4.3, and all my event dates have been shoved ahead by 5 hours, so they all read GMT rather than local time. This is the first time I've had this happen after upgrading KDE.
Upgrading from 3.4.3 to 3.5 fixed my problem, which was that events that were being read from an exchange server (stored there in UTC) were apparently not being understood by korganizer as being in UTC, so they had the offset applied again. So if I had an event at 10:00 localtime, it was stored on the exchange server as 15:00 UTC. Korganizer would read that as 15:00 localtime, and then store it as 20:00 UTC internally. It sounds like the timezone system in korganizer is just a mess. As a temporary fix it would be nice if, per calendar, you could override the timezone offsets.
Upgrading from 3.4.3 to 3.5 broke my calendars again; all my appointments are now shifted +5 hours, corresponding to my time zone (EST). I noticed that all my dates and times are stored in Zulu in the ICS files. This now appears to be taken as local time by KOrganizer. To make matters worse, the widget that selects the time zone creates a panel several times larger than my display area, so I cannot actually change the time zone to try and correct the problem.
This doesn't appear to be a glibc bug. I have 2.3.5 which is unchanged since September 2005. What worked to fix the problem for me was to set the configuration not from Settings->Configure Kontact->Calendar->Date Time, but to set the configuration from Settings->Configure Calendar->Date Time. The two seem to behave differently. When I changed the time zone to Americas/Toronto nothing happened, but when I changed it to Americas/New_York I received the correct times. To the question about keeping times the same in the calendar, I selected "Keep Times" (my calendars are stored in UTC). This suggests that the problem is in the time zone selection in KDE, not KOrganizer itself.
Am Montag, 19. Dezember 2005 15:41 schrieb Simon Clift: > To make matters worse, the widget that selects the time zone creates a > panel several times larger than my display area, so I cannot actually > change the time zone to try and correct the problem. Are you using Redhat with their self-made bluecurve style? There is a bug in that style that makes combo boxes with lots of entries practically unusable. Cheers, Reinhold
Ah ha! Vielen Dank Reinhold. That was exactly the problem (from #24 above) with the widget, and changing to Keramik did the trick.
How do I get removed from this email list?
from: http://lists.kde.org/?l=kde-pim&m=113957688207089&w=2 On Fri, Feb 10, 2006 at 08:31:02AM +0100, Birger Kollstrand wrote: > Thursday 09 February 2006 16:53, skrev Ryan Fowler: > > Hey Folks, > > > > I got pissy enough about not being able to download my Exchange calendar > > into korganizer because of the time offset that I dove in and figured out > > what was going wrong. In utils.cpp, utfAsZone is calling a function called > > icaltimezone_get_builtin_timezone_from_tzid when I think it should be > > calling icaltimezone_get_builtin_timezone. > > It is good to see that there are more KDE users needing Exchange support :-) > > If someone can help me along on how to test this on KDE 3.5.1 hen I'm more > than willing. What is the status of this über-annoying bug? It sure has rendered my KOrganizer absolutely useless.
Exactly. Exchange support is the one of the ~5 major key features stopping KDE and Linux from propagating into enterprise desktops. The answer is not to implement replacement to Exchange. Even KDE users would like to get rid of it, it's not going to happen regardless how many working alternatives there would be. Because of those rest ~4 showstoppers, KDE+Linux cannot be deployed to everyone and that is one of the reasons why Exchange will dominate. Rest of those ~4 showstoppers could be MS office+ODF issue, PDA/phone syncing, incompatible WWW services and for example poor hardware support in laptops. Solving this would bring a lot of new KDE users, increase enterprise intrest towards KDE and help to solve the other issues.
Looks like it's just occasional timezone shift. Saw this twice on KDE 3.5.1 / SUSE 10.
*** Bug 118977 has been marked as a duplicate of this bug. ***
It would be nice, if all events would be shifted by 1 hour, but what makes it worse is that some are shifted by 1 hour and others by 2 hours. I can't find any valid reason for that.
Am Mittwoch, 15. März 2006 14:46 schrieb Carsten Schlipf: > ------- Additional Comments From cs yeap de 2006-03-15 14:46 ------- > It would be nice, if all events would be shifted by 1 hour, but what makes > it worse is that some are shifted by 1 hour and others by 2 hours. I can't > find any valid reason for that. Summer time has a different offset to UTC than winter time... (in central Europe that's one and two hours, which is what you see) Cheers, Reinhold
If so, how comes that two different events, both scheduled today, show two different offsets? Does on sender has it's summer/winter time setting misconfigured? I doubt.
I keep getting these rows (constant flow) to stdout when using Exchange resource: icaltime.c:147: icaltime_from_timet() is DEPRECATED, use icaltime_from_timet_with_zone() instead so is the problem only that function name has changed? Or something bigger?
I'm experiencing the same problem. One guess I have which I haven't seen anyone else suggest: I expect Kalendar Exchange Plugin requires the remote exchange server to serve its time as UTC rather than localtime, and I imagine Exchange Server does not identify which timezone it's in. Consider the case where you are connecting to an Exchange server in a timezone different than your own. Maybe the Exchange Plugin Configure dialogue can ask which timezone the exchange server is in, and/or can ask for an offset to apply to its times?
Looks like this bug is open since two years at least. As long as this problem is not solved, korganizer is not usable in a Exchange-Server environment. This bug exists on all systems/distibutions im am aware of and that's quite a few. I just can't believe this snags to be so hard to fix.
To me it seems that this got partially resolved recently with KDE 3.5.2. *Some* events are not shifted any more. It appears that the newer events are OK, while older reoccuring events are still shifted by 2 hours. Don't know if there was something fix, or if it is just the end of the daylight saving time period. Too bad that a new bug was introduced, which is even worse: #124885 :-( Sorry, but that's it for KDE on my corporate desktop :'-(. I really miss it.
According to the comment #3 from Bram Schoenmakers on Bug 124885 (https://bugs.kde.org/show_bug.cgi?id=124885) the exchange plugin will no longer be under development. Does this affect this bug also?
@ #40 - No, it's not just exchange calendars that are affected. However, the KDE4 calendar system will store timezone data in each datetime, so this bug will be solved then.
Could this be fixed into 3.5.x? KDE4 will take long time to be realeased, another long time to be stable enough for production.
Reassigning all KOrganizer bug reports and wishes to the newly created korganizer-devel mailing list.
I am still seeing this bug. Sometimes Korganizer shows the times as 7 hours later than it should. This is when I have the timezone set to America/Los Angeles, but if I set it to America/Tijuana then it corrects itself. The problem is somewhat intermittent. Note that I am downloading off of an Exchange 2003 server.
Events in KOrganizer for KDE4 now store the timezone.