GNOME Bugzilla – Bug 727239
Event's in different timezones don't get shown properly (support non-Olson zone codes)
Last modified: 2019-10-10 14:00:23 UTC
I have to use an exchange server in Atlanta and CalDAV servers in the UK. Event's created on the exchange server tend to end up converted into a stupid time in EST on creation but Evolution displays them on my calendar in the UK with the appropriate offset so they look ok. California seems to assume the timezone of the event is whatever the local timezone is and I get events with peculiar offsets in the Exchange calendar.
First, please verify you've pulled the latest version of California from the git repo. A timezone fix was committed recently which may have fixed this problem. If it didn't, I need a little more information. If you look at the event in Evolution (double-click on it), which timezone is displayed? (You might need to choose View -> Time Zone in the event viewer.) Which time zone are you in? It would help if there was some way in California to view the event source, which is kind of where the rubber hits the road. I've ticketed that at bug #727265.
I did a git pull but it's still there. Evolution shows the events are in Eastern Standard Time, I'm in Greenwich Mean Time. I generally create the events in GMT as all day events for more than one day either in iOS or using Android and they get created as running from 7pm the previous day in EST to 7pm on the last day. Evolution shows them as running midnight to midnight in the GMT calendar.
What I'm asking for is called tzdata or an Olson Zone. In Evolution you have to double-click on the the event and make sure View -> Time Zone is turned on. It will display right above the Description field. It should say something like "America/New_York" or "Europe/Dublin". There are several names for Greenwich time, including "Z". The point is, this is the information California is using to determine the time zone; I'm trying to determine what your events are reporting and how that's causing a problem. Looking closer at Evolution, I also need to know how it's configured for you. In Edit -> Preferences -> Calendar and Tasks, there's three settings of interest here: * Use system time zone (it should list your system time zone next to it) * If that's disabled, what is the select time zone? * Second zone: most likely this is set to None, but if not, I'm curious what yours says
O.K. Thanks for the directions. Evolution is already using the system time zone and is set to Europe/London the second time zone is set to none. The events in question are showing exactly "Eastern Standard Time" in the timezone box It's only the events created in Android and iOS which perform this odd timezone gymnastics. California and Evolution both create the appointments in the Europe/London timezone.
Ok, that means your phone applications are using a different timezone naming scheme than the Olson zone system. I can't reproduce it with iOS's Calendar application, are you using something different to create events?
I'm using the built in Calendar app to create the appointments. I'll try and give you a quick rundown of the software that's interacting and how I'm creating events All the event's I'm creating have the "All Day" option selected and are for a duration of more than one day regardless of what I use to create them. The server is Exchange 2010 (Based in a different timezone to where I am currently) and is setup to only allow EWS, OWA and OWA-WebDAV are not allowed. The issue occurs when I use the built in exchange plugins for iOS 6.1.6 and Android 4.1.2 to create events, using Evolution to create events on the Exchange server creates them using Olsen timezones. Using the iOS CalDAV built in connector and Android with DavDroid plugin creating events on CalDAV servers creates them with Olsen timezones. Evolution can translate correctly the non-Olsen timezone information, as can the the Exchange EWS plugin for Lightening at 1st-setup.nl By the way, creating an all-day multi day event in the Exchange web interface generates an event with the "Europe/Guernsey" Olsen timezone according to Evolution (I think MS are just fucking with us at this point)
I've done more investigation and now think I know what's going on. The Exchange plugin is using Windows time zone names which are noninterpretable by GLib and libical. iCal does not specify which time zone naming convention is valid, and so this is not a violation of the spec. California defaults to your local time zone when it can't interpret a time zone. It turns out there are several data files available to convert Windows -> Olson codes, so that's probably the direction I'll go.
Are you still having this problem? I still don't have access to a calendar in the wild that exhibits this, and it's been difficult to attack because of it.
Created attachment 283292 [details] ics file showin non-Olsen TZData
Yes, I did a git pull today and it's still happening, I finally got round the the ics export you asked for too.
Looking at it I guess it's skipping the TZDATA but using the TZOFFSETFROM and TZOFFSETTO lines.
Thank you for the file -- this helps a lot. According to the .ics, the event starts at 7pm on August 24th, Eastern Standard Time. In in Pacific time and it appears for me to start at 4pm, which is correct as I'm three hours off of EST. With no other context, I would say California is doing the correct thing so far. I know you've described this to me before on the ticket, but now that I have the .ics, could you explain (a) how you created this particular event (which software you used, what times you set the event for, etc.), (b) what you expected to see, and (c) what California is showing you. You mentioned before that you're creating an all-day event (or, here, a five-day event) but this .ics shows it starting at a particular time and ending at a particular time. This is a problem with the iOS software, correct?
I create the event from my iPhone (iOS 6) as an all day event (hit the all day switch, not start and end times are available) I expect to see the event appear in the calendar in just one day California shows the event starting a few hours in the previous day and running in the expected day.
For giggles I created three one day all day events using Evolution, OWA and Android 4.1 The Evolution and OWA ones display correctly in California but the Android one shows the same offset. I'll attach the appropriate ics's below. (Just to be compleatest the Android calendar show the iOS, OWA and Android added events correctly but weirdly the Evolution one is shifted an hour into the following day no the preceding one, however I appreciate you're not here to debug Droid calendars)
Created attachment 283328 [details] Evolution created all day event showing correctly in California
Created attachment 283329 [details] OWA created all day event showing correctly in California
Created attachment 283330 [details] Android created all day event showing incorrectly in California
Oh and iOS and Evolution show all the events as being in one day. no leaking into the previous or next days.
Just one more thing. I don't think Evolution EWS back end is helping, as every other calender I view the exchange data in has the all day flag ticked except Evolution. Flag seen activated in OWA, iOS, Android and Thunderbird/Lightening (with some ews plugin from 1st-setup.nl). Although that doesn't explain how Evolution knows how to display it correctly.
I've filed a bug regarding the behaviour here https://bugzilla.gnome.org/show_bug.cgi?id=734747
I get the same error with california-0.4.0.
No, actually is a slightly different problem. When I add some calendar from webcal or ics (e.g. Facebook or Google Calendar) I get the time in UTC time and not in local time. (I'm from Italy, so I get a shift backward of 2h).
California is not under active development anymore and saw its last non-cosmetic code changes in March 2016: https://gitlab.gnome.org/Archive/california/commits/master Its codebase has been archived in https://gitlab.gnome.org/Archive/california/issues/1 Closing this report as WONTFIX as part of GNOME Housekeeping to reflect reality. Please feel free to reopen this ticket if anyone takes the responsibility for active development again. You may want to use `gnome-calendar`.