korganizer displays old appointments in UTC

[Tim Holy]

I just upgraded to intrepid beta. All of the appointments display correctly in the calendar view, but if I click on an event, the more detailed view shows the event in UTC. Similarly, double-clicking the event so that I can edit it also displays all times in UTC. However, entering a new event causes it to display in my own timezone in all views.

dpkg -l korganizer output:
ii korganizer 4:4.1.2-0ubuntu1 KDE personal organizer

[Georg Wittenburg (georg-wittenburg)]

Version: (using KDE 4.0.83)
Installed from: Debian testing/unstable Packages

There is some inconsistency in korganizer how time zones are handled: An appointment that appears at the correct local time in the calendar view is displayed with times in UTC on mouse-over, in the context view (left below the month view) and when editing. Further, the UTC times are also displayed in the "Upcoming Events" area of Kontact's summary view.

The expected behavior is that time zones are handled consistently matching the setting in Configure Calender -> Date & Time -> Timezone (which is set to Europe/Berlin, as opposed to UTC, in my case).

[Cgiboudeaux (cgiboudeaux)]

Could you please export one of the bugged entry ? (right click on the event, send as Ical file) to my email address please (kropx77 at gmail.com).

[Georg Wittenburg (georg-wittenburg)]

Done. If it helps: This entry has been generated before I switched KDEPIM to 4.x, so maybe it's a question of how korganizer 4.x handles data from 3.x.

[Cgiboudeaux (cgiboudeaux)]

Thank you, I'm looking for the reason.

[Cgiboudeaux (cgiboudeaux)]

ok so. The event you sent me doesn't mention any timezone which may explain why you see the event as UTC (I have anonymized it) :

BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 3.5//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
DTSTAMP:20080628T161217Z
ORGANIZER;CN=Event leader:MAILTO:<email address hidden>
CREATED:20080613T082059Z
UID:libkcal-668003459.247
LAST-MODIFIED:20080613T082059Z
SUMMARY:Event
DTSTART:20080625T070000Z
DTEND:20080625T080000Z
TRANSP:OPAQUE
END:VEVENT

END:VCALENDAR

[Cgiboudeaux (cgiboudeaux)]

Created attachment 25681
Test event

Try importing this test event and look at 2008/06/28 events in korganizer.

This event should display Europe/Paris as a timezone.

[Cgiboudeaux (cgiboudeaux)]

The main difference between my event and yours is the presence of timezone indications :

DTSTART;TZID=Europe/Paris:20080628T200000
DTEND;TZID=Europe/Paris:20080628T230000

[Georg Wittenburg (georg-wittenburg)]

The test event you sent me works fine. So I guess it's really a question of compatibility between korganizer 3.x and 4.x, as korganizer 4.x apparently assumes UTC if no timezone information is present while korganizer 3.x assumed my local timezone (Europe/Berlin).

Do you think it's possible to change this assumption in korganizer 4.x? The alternative would be to run the calender files through some script or import filter to add timezone information.

[Winter-s (winter-s)]

I double-checked, and KOrganizer from 3.5.9 and KOrganizer from 4.1 behave the same way; namely, if the date-time ends with a 'Z' it means UTC.

To make a date-time that will occur in your local timezone you want to not specify any timezone at all.

For example, DTSTART:20080625T070000 instead of DTSTART:20080625T070000Z

[Georg Wittenburg (georg-wittenburg)]

Sorry for the late reply, and thanks for spending your time on this.

I'd like to reopen this bug because of the following reasons:
- I don't quite follow your argument "Z means UTC". Even if that's the case, it doesn't change the fact that the events I create with 3.5.9 appear with the wrong time in 4.0.98. Unless of course you can't reproduce this, in which case I'd have to check which part of my configuration is messed up.
- Even right now, the GUI is inconsistent. Events (created with 3.5.9) show up with UTC in the dialog but at my local timezone (with the times I originally entered) in the week view.

I still think that the following components should adjust the time of events to the local timezone (even if the time is saved in UTC) just like the week view does:
- Event dialog
- Side-bar event details
- Upcoming events in the summary view

Again, thanks for your time and effort. :)

[Vdboor-f (vdboor-f)]

I find this issue very confusing too. For a moment I thought I'd missed an appointment just to figure out later it's displayed in UTC. This also happens on the "summary" panel of Kontact.

When I open the "event event" dialog, fix timezone in the event and times, it will still be displayed in UTC the next time you open the edit dialog.

[George Goldberg (grundleborg)]

To clarify a little: 'z' is short for "Zulu Time" which is another name for UTC. So, the calendar entry posted in comment #4 specifically has the timezone set to UTC, due to the "z" appearing after the time.

[Sergio-pe-facebook+kde (sergio-pe-facebook+kde)]

I have the same problem. The time of the events appears correctly in the following views: Day, Week, Working Week and List of Events, but not in Month View (it shows the UTC times).

[Sergio-pe-facebook+kde (sergio-pe-facebook+kde)]

Created attachment 27649
Image showing different times for the same events.

[Sergio-pe-facebook+kde (sergio-pe-facebook+kde)]

I forgot to say that my local time is Europe/Madrid, GMT +1:00

I'm sorry T_T

[Crust (crust)]

(In reply to comment #0)
> Version: (using KDE 4.0.83)
> Installed from: Debian testing/unstable Packages
>
> There is some inconsistency in korganizer how time zones are handled: An
> appointment that appears at the correct local time in the calendar view is
> displayed with times in UTC on mouse-over, in the context view (left below the
> month view) and when editing. Further, the UTC times are also displayed in the
> "Upcoming Events" area of Kontact's summary view.
>
> The expected behavior is that time zones are handled consistently matching the
> setting in Configure Calender -> Date & Time -> Timezone (which is set to
> Europe/Berlin, as opposed to UTC, in my case).
>

I am also having a similar problem when switching from week to month view in Calendar. If it is of any interest to anyone that is actively tackling this bug, I currently have both 'broken' and normal entries. I can provide these to whoever is interested.

[hansg (hans-gunnarsson)]

I have the same behavior as #12
We are using Kolab as our groupware server, with KDE 4.1.2 and Korganizer 4.1.0 on OpenSuSE 11.0

[Harald Sitter (apachelogger)]

The problem is that KDE 3 didn't store the timezone along the time, so KDE 4 apparently assumes it is UTC and does the default operations for not-locale times, it translates them into your locale one.
However, the entry in the calendar file itself is not changed, and the general assumption seems to be that editing an entry should by default use the entries time in a non localized manner (or maybe that just applies to such entries without time zone definition).

Anyway, I am not sure this actually should be changed/can be changed in a sensible way. There probably are cases where you want to keep a UTC using file. KOrganizer can't determine if the file is applying to that use case, of it is just a KDE 3 one.
So my point of view is that as long as the event shows correctly in the calendar view this issue is only of very minor importance, recurring ones, which would be most affected I guess, would only need to be canged once anyway.

[Tim Holy (holy-wustl)]

Well, it does cause a bug: evening appointments made here in the America/Chicago timezone end up being displayed on two consecutive days. (See attached screenshot; Monday's "Soccer" and "Juniors" should _not_ be replicated on Tuesday.)

Aside from dozens of recurring items, I also have non-recurring events scheduled as far as 2 years in advance. It must be hundreds of items. That does mean that this bug will be with me for years to come.

Any chance of a conversion script? One that would insert proper timezone info into the calendar file?

[Harald Sitter (apachelogger)]

Well, the display issue is actually a different one ;-)

I guess writing a conversion script wouldn't be much work, but we can not run it by default because of the reason stated in my former comment.

[Harald Sitter (apachelogger)]

I am attaching a script to convert the calendar files. By default it will use $HOME/.kde/share/apps/korganizer/std.ics, you can change this by passing a different file as argument to the script
   ruby migrateics.rb /home/harald/.kde/share/apps/korganizer/private.ics
for example.

It copies the file to $HOME before doing anything, in case something goes wrong :)

[Tim Holy (holy-wustl)]

Thanks for the script! That's incredibly generous of you to provide this---to people like me who don't tend to make appointments in many different timezones, this will save a lot of manual work.

I think I almost have your script working, with the one small exception that the output std.ics (as well as the "backup" in $HOME) are blank. :-) Fortunately, being paranoid by nature I made my own backup, so no harm's done.

To run it I had to install libruby1.8-extras as well as ruby1.9 (because of gsub). Is the version mismatch the probable cause of the script error?

Here's what I did to run it, and its output:
tim@diva:~$ ruby1.9 ./migrateics.rb
copy backup of /home/tim/.kde/share/apps/korganizer/std.ics to /home/tim
opening /home/tim/.kde/share/apps/korganizer/std.ics for editing
closing file object #<File:0x91432ec>, finished editing

But the resulting files are blank. Any thoughts?

[Harald Sitter (apachelogger)]

You are running Intrepid, right?

[Tim Holy (holy-wustl)]

Oh, and on "the display issue is actually a different one," I agree this observation does add some new elements---and I suspect you've already diagnosed the problem better than I. However, at the risk of being unnecessarily explicit: note that those evening appointments span 2 days as measured by UTC (6pm-7:30pm America/Chicago is 2300-0030 UTC). So it seems that the decision about which days to display the event on is being made before the conversion to the local timezone. So this "new" bug should be fixed by doing the timezone conversion first, I'd guess.

That said, I bet the double-display bug won't be triggered nearly as often if the std.ics file is converted to use local timezones first. So your script (once it works more broadly) should resolve this problem for many people, even if there's a second problem that also needs to be addressed.

Should I open a separate bug report for the double-display problem?

On scripts: also note http://chandlerproject.org/Projects/OlsonConvert. However, when I try to run this script on my std.ics file, I get a "year is out of range" error.

[Tim Holy (holy-wustl)]

On Tuesday 21 October 2008, Harald Sitter wrote:
> You are running Intrepid, right?

Yes. I just found "libruby-extras" (I had only noticed libruby1.8-extras
before) and installed it. Then I get this output:

tim@diva:~$ ruby1.9 ./migrateics.rb
copy backup of /home/tim/.kde/share/apps/korganizer/std.ics to /home/tim
opening /home/tim/.kde/share/apps/korganizer/std.ics for editing
./migrateics.rb:52:in `block (2 levels) in <main>': undefined method `gsub!'
for nil:NilClass (NoMethodError)
        from ./migrateics.rb:51:in `each'
        from ./migrateics.rb:51:in `block in <main>'
        from ./migrateics.rb:47:in `each'
        from ./migrateics.rb:47:in `<main>'

This time, the copy of std.ics in $HOME is intact. I'm guessing I'm missing a
package that defines the gsub method?

[Harald Sitter (apachelogger)]

I attached a modified script, maybe it works better. I am not exaclty sure why it fails there.

Anyhow the extras package is only necessary for the backup task. gsub! as well as everything else (besides the copy operation obviously ;-) is part of the core ruby modules, so I don't see how that could be the problem.

[Tim Holy (holy-wustl)]

On Tuesday 21 October 2008, Harald Sitter wrote:
> I attached a modified script, maybe it works better. I am not exaclty
> sure why it fails there.
>
> Anyhow the extras package is only necessary for the backup task. gsub!
> as well as everything else (besides the copy operation obviously ;-) is
> part of the core ruby modules, so I don't see how that could be the
> problem.

Sorry to not be able to report success, but I'm still getting an "undefined
method `gsub!' for nil:NilClass" error. Does nil:NilClass mean it doesn't know
the class of "line"? Sorry, I just don't know ruby at all, so I'm pretty
useless here.

For completeness, here are my ruby-related packages:
tim@diva:~$ dpkg -l *ruby* | grep ii
ii libbreakpoint-ruby1.8 0.5.1-2
Ruby library for adding breakpoints to Ruby
ii libcmdparse2-ruby1.8 2.0.2-2
Advanced command line parsing module support
ii libdaemons-ruby1.8 1.0.10-2
Ruby daemons library
ii liblog4r-ruby1.8 1.0.5-7
A logging library for Ruby
ii libmmap-ruby1.8 0.2.6-3
Ruby interface to manage memory-mapped file
ii libncurses-ruby1.8 1.1-3
ruby Extension for the ncurses C library
ii libopenssl-ruby1.8 1.8.7.72-1
OpenSSL interface for Ruby 1.8
ii libreadline-ruby1.8 1.8.7.72-1
Readline interface for Ruby 1.8
ii libruby-extras 0.4ubuntu2
a bundle of additional libraries for Ruby
ii libruby1.8 1.8.7.72-1
Libraries necessary to run Ruby 1.8
ii libruby1.8-extras 0.4ubuntu2
a bundle of additional libraries for Ruby 1.
ii libruby1.9 1.9.0.2-7
Libraries necessary to run Ruby 1.9
ii ruby 4.2
An interpreter of object-oriented scripting
ii ruby1.8 1.8.7.72-1
Interpreter of object-oriented scripting lan
ii ruby1.9 1.9.0.2-7
Interpreter of object-oriented scripting lan
ii rubygems1.8 1.3.0~RC1really1.2.0-2ubuntu3
package management framework for Ruby librar

>
> ** Attachment added: "migrateics.rb"
> http://launchpadlibrarian.net/18773605/migrateics.rb

[Tim Holy (holy-wustl)]

On Tuesday 21 October 2008, Harald Sitter wrote:
> I attached a modified script, maybe it works better. I am not exaclty
> sure why it fails there.

OK, I googled and I think I found part of the problem, but I don't understand
the whole thing. "line" turns out to be empty sometimes. So I changed line 54
from "end" to "end if line" and now it runs without error. But, it turns out
that it never executes the loop: it seems that "line" never contains valid
input. I tried changing the split character from \n to : or a space and still
never had the loop execute (as determined by putting a 'print "Looping\n"'
line as the first element of the loop).

However, str is not empty; a print str reveals the entire ics file.

>
> Anyhow the extras package is only necessary for the backup task. gsub!
> as well as everything else (besides the copy operation obviously ;-) is
> part of the core ruby modules, so I don't see how that could be the
> problem.
>
> ** Attachment added: "migrateics.rb"
> http://launchpadlibrarian.net/18773605/migrateics.rb

[Harald Sitter (apachelogger)]

New try.

In theory line can never be nil, it can be an empty string (i.e. "") but never nil (which would be nothing at all). I add a control strucutre to prevent an execution of gsub on line, when line is nil.
I am not too sure if this works though, in order to evaluate the variable the variable mustn't be nil (in theory again ;-)

Anyway, please give it a try.

[Tim Holy (holy-wustl)]

Definite progress, in that it processes the entire file. The lines it changes
(because they start with DTSTART or DTEND), however, come out blank, rather
than containing data. This causes korganizer to crash on startup.

As I try to understand more ruby, it looks to me like your script just
prepends my timezone but does not actually convert the time to my timezone.
Won't that introduce a problem? I.e., the time will no longer be the
equivalent of the UTC? Or does "Z" mean "the local timezone"?

I'm beginning to wonder if the more straightforward approach would be to look
for regexps of the form "[0-9]\{8\}T[0-9]\{6\}Z" (8 digits followed by T
followed by 6 digits followed by Z) and parse the string to convert the time.
If this is something that you are interested in seeing done, I'd be delighted
to keep working with you on this; if you're growing tired of this and don't
think others will get much benefit out of it, I might try to code something up
in matlab (a language I am fluent in) for my own purposes only.

[Harald Sitter (apachelogger)]

There is no conversion going on.
The only changes that need to be done is attach ;TZID=#{timezone}: to DSTART/DTEND and remove the trailing Z, in fact just removing the Z should b enough to force KOrganizer to use the local time. It is however adding the timezone from /etc/timezone to ensure it uses the correct one.

I attached yet a new try to resolve the issue, which should actually work with ruby1.8 in Intrepid. It also features a more verbose output of what is going on. If that doesn't work either you can write a script yourself or (if you trust me enough ;-) send me the calendar file so I don't have to be poking in the dark.

[Tim Holy (holy-wustl)]

OK, thanks for the updated script! It runs to completion, and indeed prints debugging info. The curious part is that the typical event looks like this:

......BEGIN:VEVENT
......DTSTAMP:20081022T164250Z
......ORGANIZER;CN=Tim Holy:MAILTO:<email address hidden>
......CREATED:20060412T212539Z
......UID:libkcal-1053224003.358
......SEQUENCE:1
......LAST-MODIFIED:20060413T131556Z
......SUMMARY:Some event
......PRIORITY:3
......LINESTARTSWITH DSTART: DTSTART:20060428T154500Z
......LINESTARTSWITH DSTART GSUBBED: DTSTART:20060428T154500Z
......LINESTARTSWITH DSTART: DTEND:20060428T163000Z
......LINESTARTSWITH DSTART GSUBBED: DTEND:20060428T163000Z
......TRANSP:OPAQUE
......END:VEVENT

So, oddly, the gsubbing doesn't seem to be doing anything: the gsubbed version is the same as the original.

Ah, but wait! I made a stab in the dark and replaced the two gsub lines with
            line = line.gsub("Z","")
            line = line.gsub("#{replace}:","#{replace};TZID=#{timezone}:")
i.e., inserted the "line = " part in front. This seems to work properly, with one funny exception: any line that already had a "TZID" (e.g., appointments I've made since upgrading and working this issue out) got replaced with a "TID" because of the gsubbing "Z" to a "". So, is there a way of insuring that the match to Z occurs only at the end of the line?

I'm happy to send you the calendar file off-line, if you wish. You can email me directly, my last name followed by wustl and then a dot and then edu (parse that, spammers!)

[Tim Holy (holy-wustl)]

OK, I did more reading (ruby is pretty cool). The "Z" substitution line can be changed to
            line = line.sub(/Z[\r$]/,'')
and I think the script works as you intended. (The \r part is needed because korganizer seems to save its data in a DOS-style text file; I put the $ in there for safety.)

However, it turns out that the concern I raised above about not converting the times is indeed a problem. Here's why: in scheduling, korganizer has already done the conversion to UTC when it saves an event in the format YYYYMMDDTHHMMSSZ. If we just strip the Z off the end without converting to local time, then all the times will be off by the UTC offset.

So I poked around and came up with a solution. I've attached a script that seems to work for me. I had to install the "tzinfo" gem http://tzinfo.rubyforge.org/doc/files/README.html

and I run this script with
ruby -rubygems migrateics.rb

One oddity: when I first start kontact, switching to the "calendar" component of kontact now takes much longer than it used to: 20 seconds! It used to take 4 seconds.

One other issue: suppose the script bombs on certain std.ics files (it works on mine, but just suppose), so that it either deletes the data or converts it into something that crashes korganizer (which I've now done a lot recently). If the user runs the script twice, without copying the backup std.ics from $HOME back to .kde/share/apps/korganizer in between, then the user won't have any backup of his/her data. Would it be worth checking to make sure that the "make a backup copy" step doesn't overwrite an existing file?

Once these last points are taken care of, I imagine this script might be ready for wider use.

[Tim Holy (holy-wustl)]

Oh, it also turns out that it becomes much slower to "scroll" (i.e., when you hit the "back" and "forward" buttons), so much so that I will for now keep using my old UTC-based std.ics. Drat. Presumably this is something that could be optimized? Like I said earlier, I'm happy to mail you my calendar file if you want to use it to callgrind korganizer something.

Doing the migration does fix the double-printing bug, however. That's something!

[Tim Holy (holy-wustl)]

See upstream bugreport http://bugs.kde.org/show_bug.cgi?id=165212. I've put a link to this thread there, too.

[Holy-t (holy-t)]

There's a conversion script in-progress at https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/286567
(See the _final_ version of the migrateics.rb script, or at least the one posted no earlier than Oct 23, 2008.)

This script will go through your std.ics calendar file and convert all your appointments to your local timezone. This seems to fix the issue.

However, it also seems to negatively affect the performance of korganizer with large std.ics files, so for the time being I don't recommend it. (Kubuntu Intrepid beta packages.)

Also, if you run it I highly recommend making a manual backup of your std.ics file first. (It makes its own backup, but doesn't check to see if it's overwriting a previous backup, and this could lead to data loss if the script is run twice.)

[hansg (hans-gunnarsson)]

Just want to clarify. For me this occurence is not dependent on creating the appointment in 3.5.X and viewing it in 4.1.X

Any appointment I create in 4.1.X gets converted to UTC even if I create it with my timezone (Europe/Sweden).

Maybe this is because we use Kolab as backend? This also means that the script in Comment #17 doesn't help.

[Winter-s (winter-s)]

Ok, these bug occurs for any incidence that is stored in a calendar with UTC timezone.

I just committed a fix in trunk that should handle all the places mentioned in this bug report where datetimes for UTC timezone is not shown in the user's configured timezone.

I may not be able to backport these fixes to 4.1 because a change to a kdepimlibs library is required. I'll see what I can do.

I won't close this bug for now because there might be more places that need timezone conversion that we haven't found yet. please let me know if you find more cases.

[Harald Sitter (apachelogger)]

I added a bug watcher for the KDE bug, so we can easily follow it's status.

Anwho, the slowness could be what is reported as bug #258611 I am not sure though, as I wasn't able to reproduce it.

By the way, my KOrganizer didn't store the files with dos file ending :P

[Ludda512 (ludda512)]

I'm having a similar issue with the week view giving me the correct times and in UTC format. The month view is 4 hours off on all appointments. However, I do use Kolab as a groupware server 2.2 and I have outlook with the konsec connector. It appears if I add an event through kontact the correct timezone information is honored. However, If i add an event through horde web or konsec(outlook) it seems to not recognize the format and uses UTC. I have also seen this cause duplicate appointments. this probably due to it not recognizing the format. I can provide copies of appointments if you wish to view. It seems that a lot of this has already been mentioned and similar to what I'm experiencing now. I have
1 KDE Version 4.1.0 (KDE 4.1.2 (KDE 4.1.2), Kubuntu packages)
1 Application Organizer
1 Operating System Linux (x86_64) release 2.6.27-7-generic
1 Compiler cc

[nola mike (abatzis)]

it's definitely a problem with kontact itself. if the .ics file has the times listed in UTC (times end with "z"; this seems to be the standard across several platforms, don't know if it's the ical standard or not), calendar will display UTC times in the month view, but correctly display local time in the week/day views. if a new event is entered through kontact, it is saved with a TZID= sub field in DTSTART/DTEND, and the local time. i worry a bit about changing the syntax of the DTSTART/DTEND fields, but my older version of kontact on a different desktop, as well as gpe on a nokia n800 seem to parse the TZID info correctly. lastly, kontact displays times correctly across all views if the TZID info is included in the ics file.

[Holy-t (holy-t)]

(In reply to comment #19)
> I just committed a fix in trunk that should handle all the places mentioned in
> this bug report where datetimes for UTC timezone is not shown in the user's
> configured timezone.

Sorry for the delay in saying something important: thanks very much, Allen!

>
> I may not be able to backport these fixes to 4.1 because a change to a
> kdepimlibs library is required. I'll see what I can do.

It would be great to get it for 4.1, but if not, well, I look forward to 4.2.

>
> I won't close this bug for now because there might be more places that need
> timezone conversion that we haven't found yet. please let me know if you find
> more cases.

It might be worth checking to see if this also fixes bug 173381 that I reported. If so, that bug report could be closed.

Finally, I reported potential performance issues with timezone conversion in bug 173383. If your patch reverts kontact to saving the event in UTC, however, this performance bug probably won't be triggered.

[Georg Wittenburg (georg-wittenburg)]

Created attachment 29849
Screenshot

I think this bug is mostly resolved. The only issue that remains is that the editor view of an appointment defaults to a different timezone than the one used for display (see attached screenshot).

[nola mike (abatzis)]

bug is definitely still present for me, using kontact 1.8/kde 4.1.3

[Holy-t (holy-t)]

(In reply to comment #23)
> Created an attachment (id=29849) [details]
> Screenshot
>
> I think this bug is mostly resolved. The only issue that remains is that the
> editor view of an appointment defaults to a different timezone than the one
> used for display (see attached screenshot).
>

I'm glad that some of the other GUI inconsistencies have been fixed. Does this fix bug 173381? If so, it could be closed.

However, the editor view has always been the most annoying aspect of this bug for me, so please do leave this bug open.

[Ludda512 (ludda512)]

Created attachment 31056
month view showing wrong on wrong date

[Ludda512 (ludda512)]

I have korganizer 4.2 rc 1 on kde enviroment 4.2. When scheduling the month view reverts still to UTC. As well sometimes the appointments do not even reflect on correct day. As well as the appointment doesn't even show up under week view but will show up on incorrect day on month view. I have sent in an attachment showing this. the attachment shows this particular appointment in the month view and under the week view it doesn't show up at all. If you wish for more information or if i'm beating a dead horse and the issue has already been addressed let me know.

[Holy-t (holy-t)]

James, your issues sound a lot like bug 173381. So you've answered my question above (comment #25), I guess that bug can't be closed yet (unless it was fixed between RC1 and the release).

[Mike Eager (eager)]

I added a python script at https://bugs.kde.org/show_bug.cgi?id=165212 which is similar to the ruby script.

[Mike Eager (eager)]

Created attachment 31159
Migrate ICS from KDE 3.x to KDE 4.x

Python script to rewrite time/date in cal.ics file.

[Mike Eager (eager)]

I've added a python script which rewrites the DTSTART/DTEND lines in an ICS
file to add time zone info and adjust the time. This is similar to the ruby
script mentioned in comment #17, except that (1) I had problems with the ruby
and all of it's dependencies on Fedora 10, (2) it doesn't require /etc/timezone, and (3) it doesn't modify the installed std.ics calendar (which
clobbered my calendar when dependencies were missing).

The calendar is adjusted to the local time zone, including adjusting date and time and inserting the time zone name you specify.

The time zone name should match the current time zone. It's not possible (as written) to adjust a calendar to a time zone other than your current time zone. I've only tested this for my time zone.

Example:
  ./migrateics.py America/Los_Angeles ~/.kde/share/apps/korganizer/std.ics >
new.ics
  cp ~/.kde/share/apps/korganizer/std.ics ~/.kde/share/apps/korganizer/std.ics~
  cp new.ics ~/.kde/share/apps/korganizer/std.ics

[nola mike (abatzis)]

for me, this issue seems to have resolved with stable kde 4.2/kontact 1.4.

[Mike Eager (eager)]

Nola -- Could be. I'm using Fedora 10, which has KDE 4.1.4. Updated KDE 4.2 packages are not available.

[Nereusren (nereusren)]

The Month View displayed time seems to be fixed in 4.2 for me (using the ubuntu packages). Thanks for fixing this! It is the bug standing in the way of my automatic two-way calendar sync between Kontact<->GoogleCalendar<->iPhone, since Google Calendar's .ics file stores its times using the "Z" suffix.

Unfortunately, it seems to still use the UTC time/date for some things. I don't know if they should go in a different bug report or keep this one open.

For example, say I have two events on my calendar: one ("event G") at America/Chicago 3:00 imported from my Google Calendar's .ics file, and one ("event K") at America/Chicago 5:00 created with Konqueror. They will display in the wrong order on the Month View:

5:00:00 Event K
3:00:00 Event G

Presumably Event G is still being sorted based on its UTC time of 9:00.

Also, the event will appear under the date associated with the UTC time, rather than the local time. If there's an event on my Google Calendar for 21:00 America/Chicago on February 27th, in the month view it will show up under February 28th. (The tooltip and event info/summary box (on the left) display the local time and date properly.)

[Fischer-michael (fischer-michael)]

Created attachment 33306
Modification of Michael Eager's code to migrate ICS from KDE 4.x to KDE 4.x.

This script is daylight savings time aware and applies the offset from UTC in effect on the date of the event rather than the offset in effect on the date that the script is run.

[Uli-2001 (uli-2001)]

Here is my experience with this issue:

My computer runs on UTC (I am not sure whether this matters), and I am in the Los Angeles timezone. I am using KOrganizer, saving events to calendar that is on disconnected IMAP (the events are stored as emails with a file kolab.xml attached).

I add an event on May 19 at 17:00 Los Angeles time to KOrganizer.

After restarting KOrganizer, the event shows up on May 20 at 17:00 in the weekly or monthly view. When I click on it, the sidebar of the event says May 19, 17:00. In the daily view, it shows up neither on May 19 nor on May 20.
Doubleclicking on the event shows that it is saved as starting on May 20 at 0:00 UTC (which is correct, but confusing, I think - it is the same as May 19, 17:00 Los Angeles time).

So my complaints are:
1. the event shows up wrong in the daily/monthly/weekly view.
2. when editing the event, shows up in UTC, which makes it harder to edit when I want to move it to a different time.

[Uli-2001 (uli-2001)]

Here is my experience with this issue. I use KDE 4.2.3 on Opensuse 11.1 (from Opensuse's KDE4 repository).

My computer runs on UTC (I am not sure whether this matters), and I am in the Los Angeles timezone. I am using KOrganizer, saving events to calendar that is on disconnected IMAP (the events are stored as emails with a file kolab.xml attached).

I add an event on May 19 at 17:00 Los Angeles time to KOrganizer.

After restarting KOrganizer, the event shows up on May 20 at 17:00 in the weekly or monthly view. When I click on it, the sidebar of the event says May 19, 17:00. In the daily view, it shows up neither on May 19 nor on May 20.
Doubleclicking on the event shows that it is saved as starting on May 20 at 0:00 UTC (which is correct, but confusing, I think - it is the same as May 19, 17:00 Los Angeles time).

So my complaints are:
1. the event shows up wrong in the daily/monthly/weekly view.
2. when editing the event, shows up in UTC, which makes it harder to edit when I want to move it to a different time.

[Smartins (smartins)]

(In reply to comment #35)
> After restarting KOrganizer, the event shows up on May 20 at 17:00 in the
> weekly or monthly view. When I click on it, the sidebar of the event says May
> 19, 17:00. In the daily view, it shows up neither on May 19 nor on May 20.
> Doubleclicking on the event shows that it is saved as starting on May 20 at
> 0:00 UTC (which is correct, but confusing, I think - it is the same as May 19,
> 17:00 Los Angeles time).
>
> So my complaints are:
> 1. the event shows up wrong in the daily/monthly/weekly view.
Fixed in trunk and for KDE 4.2.4

> 2. when editing the event, shows up in UTC, which makes it harder to edit when
> I want to move it to a different time.
Was it created with KDE3? Change it's timezone to America/LA and it should be ok.

[Georg Wittenburg (georg-wittenburg)]

I can't reproduce this bug anymore, mostly for lack of pre-4.x korganizer events, and am closing this bug. Please reopen if anyone can still reproduce this.

[Fischer-michael (fischer-michael)]

Created attachment 41415
Test case showing UTC bug

This bug is alive and well, or at least some version of it is, in KOrganizer Version 4.4. Attached file contains one event beginning beginning on Sunday, March 14, at 0100 UTC and ending at 0500 UTC. My time zone (America/New York (EST)) is -5 hours away from UTC, so in local time, this should start on Saturday, March 13 at 8 pm and end at midnight the same day.

To witness this bug, use the KDE control panel to set your time zone to America/New York (EST), then open the attachment in KOrganizer. Select either "Day" view or the "Week" view. The test event will appear on *both* Saturday, March 13 *and* on Sunday, March 14. Each shows the correct time span, 08:00 pm - 12:00 am local time. Now go to the "Month" view. This shows correctly that the event occurs at 08:00 pm on Saturday, March 13, but it also shows a bogus event on Sunday, March 14, at 12:00 am.

Apparently, the filter that selects *which* events to display is not correctly converting from UTC to local time, although the time conversion is done correctly when the event is actually displayed.

Workaround: Avoid UTC times in .ics files; use local times instead.

[Georg Wittenburg (georg-wittenburg)]

Reopened, given Michael's new test case above. Thanks.

[Harald Sitter (apachelogger)]

Closing in favor of KDE report. Please refer there for updates. Thanks.

[Kdenis (kdenis)]

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of korganizer (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.

[Fischer-michael (fischer-michael)]

The bug I reported in Comment 39 is still with us in korganizer version 5.3.0 (QtWeb Engine).

Attachment 41415 contains a calendar with one appointment "Test event" on Sunday, March 14, 2010, 1:00 AM - 5:00 AM UTC. In terms of local time (America/New York), the above appointment begins at 8:00 PM on Saturday, March 13 and ends at 12:00 AM on Sunday, March 14.

When displayed in the day or week agenda view, the appointment displays as Saturday, March 13, 2010, 8 :00 PM - 12:00 AM, and nothing displays on Sunday, March 14. However, in the month view, the appointment spans two days, displaying on both March 13 and March 14.

There is also a UTC conversion problem. If one takes that same appointment but changes the ending time to 9:00 AM UTC on Sunday, March 14, 2010, it displays incorrectly as ending at 4:00 AM local time. Since daylight savings time began at 2:00 AM on Sunday, March 14, 2010, the ending time should have displayed as 5:00 AM local time.

[Cgiboudeaux (cgiboudeaux)]

Thanks for the feedback.

[Bug-janitor (bug-janitor)]

A possibly relevant merge request was started @ https://invent.kde.org/pim/eventviews/-/merge_requests/19

[Glen Ditchfield (gjditchfield)]

Git commit 2324098a8ffcf59d4e88c2c84ba2a288b8e9e783 by Glen Ditchfield, on behalf of Glen Ditchfield.
Committed on 04/02/2021 at 16:07.
Pushed by gditchfield into branch 'release/20.12'.

Fix month view's display of end-of-day instances

If a non-all-day instance extends to the end of a day, its dtEnd will
be 00:00 of the next day. The month view incorrectly shows the instance
occurring on both days.
FIXED-IN: 5.16.3

M +5 -1 src/month/monthitem.cpp

https://invent.kde.org/pim/eventviews/commit/2324098a8ffcf59d4e88c2c84ba2a288b8e9e783