GNOME Bugzilla – Bug 347845
Early Hour AM iCal Calendar Entries Do Not Load
Last modified: 2013-09-10 14:04:39 UTC
Please describe the problem: Items that are in a .ics file in times like 1-4am to not appear correctly in the Daily View only. The Weekly and Monthly view works fine. When I hand edit the entry and move it later in the day past 4am, it works just fine. Attaching my work files. shot1.png - 2 early am entries, work fine in weekly view shot2.png - Clicked into daily view, only 4-5am item shows, 3-4am items does not appear, YET, it does bold the date as having an item. badical.ics - my test file Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 69072 [details] Weekly View, works fine
Created attachment 69073 [details] Click into daily view, and item at 3-4am does not display
Created attachment 69074 [details] Test File, very simple ical file
hmm. works fine here, evo 2.7.4cvs.
Tested on Suse 9.3 build and on SLED 10, broken on both platforms in 2.6.x
Can not confirm either, WORKSFORME. Tested this 2 different ways: a) Importing the provided iCalendar file. b) Copy the provided test case. Just one minor change to both Summary fields, added a trailing string to verify this being the copy. Evolution 2.6.2, GNOME 2.14.2, almost vanilla build by GARNOME.
Tested as webcal, served by apache. Works just fine, too.
Yes, it seems to work fine with the cvs HEAD build. Poornima, could you please verify this with sled 10 rpms given to dave.
Ok, in conversation with Guenther and poking around I have determined: 1) This only happens when using "On The Web" with webcal:// 2) This same file imports and displays fine using File >> Import 3) File that Guenther placed on the web outside of our network failed as well. 4) When you Save this calendar to disk, it writes out both entries..including the one that doesn't not display the GUI. 5) A diff of the two shows they are the same, except the DESCRIPTION: line has been split into 2 smaller pieces. I just tested on SL 10.0 with stock Evolution and it fails there as well. Please confirm that you saw TWO entries for this .ics file and not just the one. I put in two entries...one works, and one an hour earlier does not. It fails on: Evolution 2.6 on Suse 9.3 Evolution 2.6 on SLED 10 Evolution 2.4 on SL 10.0
On further IRC discussion: The base GNOME is <= 2.12.x always. Also, all versions Dave tested are based on the SuSE packages for Evo, AFAIK, even the custom builds for Largo. On the other hand, I am running an almost plain vanilla GNOME 2.14.x Desktop, built from sources (using GARNOME), distro Mandriva. Can not reproduce the issue. Andre can not reproduce using Evo 2.7.x built from source, running on SuSE 10.1 (GNOME 2.12.x). So the single-point-of-failure I do see here is that all affected versions are based on the same SuSE build (AFAIK, not sure). We are unable to reproduce on source builds. Outstanding test: Reproducible on a non-SuSE package? Maybe a SuSE specific/custom patch is the cause here? I am pretty positive this is NOTGNOME, though I'd like to see more evidence. Any test using a package from another distro would be appreciated.
(In reply to comment #9) > Please confirm that you saw TWO entries for this .ics file and not just the > one. I put in two entries...one works, and one an hour earlier does not. Yes, two appointments, one at 3 AM, the other at 4 AM. Saw both in any View I checked, including the Day View.
Random speculation, some screwup in determining what events are in a day based on timezone? I'm on EDT which is -4 or -5, if one check was using UTC and another TZ, something could disappear... Fails in Gentoo x86 ARCH though. [ebuild R ] mail-client/evolution-2.6.2-r1 USE="crypt gstreamer ipv6 kerberos ldap mono spell ssl -bogofilter -dbus -debug -doc -hal -krb4 -nntp -pda -profile -widescreen" 0 kB
I went into Evolution and using the UI changed the time zone from EDT to Germany, and closed and reopened Evolution and the .ics file from webcal:// displays just fine. So it's definitely related to time zone.
Ok, when I checked Pacific, Mountain and Central time the meetings are completely hidden and don't display at all. When I move into EDT + 1 hour they both appear.
I stand corrected... Confirming according to comment 12 and comment 13. Thanks for testing this. Appears to be a bad timezone check/calculation. Interestingly done only for webcal Calendars, not when importing.
Can confirm myself now, chosing timezone America/New_York in the Calendar preferences. Note: The Day View does *not* show the 3 AM appointment. Week View and Month View do show it. Raising priority. This is a *nasty* bug, and the user losing information based on their timezone. Thus this potentially will affect daylight times, too.
*sigh* I should not be allowed to test this. More info. Switching between America/New_York to Europe/Berlin did *not* make the 3 AM appointmente re-appear. Also, disabling and enabling the webcal does not. Even when back in the timezone that used to show the 3 AM appointment, it will not be shown.
added guenther's webcal calendar. set evolution calendar timezone to new york. i can confirm that i cannot see the first appointment with evolution 2.7.4. changing back to europe/berlin does not make the first appointment reappear.
Created attachment 69190 [details] QA .ics file, 24 1-hour meetings
Germany is losing 10-11pm and 11pm-midnight. Eastern is losing midnight-1am, 1am-2am, 2am-3am, 3am-4am
okay. day view. it seems like it's only a painting issue. example: - set evo's timezone to America/Vancouver UTC-0700 - import dave's ics file. - set evo's timezone to Indian/Maldives UTC+0500 - see that the appointments are only displayed from noon to midnight, because of the 12 hours difference between the timezones. - use the mini calendar to go to another day and back again. now everything is displayed correctly.
Target this for 2.6.3
2.8 now, it seems.
It seems to me like fixed. At least no data lost there like mentioned above. I only noticed warnings like this: (evolution:3576): calendar-gui-WARNING **: Invalid date range for event which are probably caused by moving event time when computing from event's time zone to evolution's time zone (just a guess).
I tried to import both test calendar files to my local (personal) calendar in evolution 2.29.2 and it works fine, I see all those events. I can see them in 2.28.2 too. You said it doesn't work for you in 2.24. if you've some event, could you place here its source (not the one exported from evolution), please? Please strip all the private information from there, like summaries and attendees/organizers, if any, just keep the timezone information and times as they are. Thanks in advance.
Hmm, just thinking, what is your calendar you are importing the event to, and what is your evolution time zone set?
Just by an accident I noticed the behaviour of this with a MAPI calendar. I exported the file and imported it back to a local calendar and there it works fine. So the calendar source is important here. It's probably not handling the timezones properly, because I have a local timezone Europe/Prague and the event's timezone is /softwarestudio.org/Tzfile/America/New_York.
Created attachment 147598 [details] [review] proposed eds patch for evolution-data-server; This will help with any backend, though I can do the same for MAPI only. With MAPI itself will be needed a bit more, because if has its own src/libexchangemapi/tz-ical-to-mapi and tz-mapi-to-ical files, where is the prefix prewritten, but the actual libical prefix is different. (There is supposed to be a mapping between libical timezone IDs and MAPI timezone names, I guess.)
This seems to be a case specific to mapi, would be good to have the changes in mapi backend.
(In reply to comment #29) > This seems to be a case specific to mapi, would be good to have the changes in > mapi backend. I did them within bug #586203, but note this bug report is far long time before mapi, and I guess Dave is using GroupWise, so that might be either something else, or the fix should be better done as I suggested in the patch. From my point of view the changed code is usually used as a fallback, if everything fails, thus I believe it's a correct fix, or at least better than it is working now.
Comment on attachment 147598 [details] [review] proposed eds patch This might need to go prolly in e-cal-check-timezones.c where we do the similar check.
Had a discussion with milan over irc and it makes sense. Go ahead with committing :)
Created commit 1702e84 in eds master (2.29.3+)