The timezone is taken from FAS. I can't create events in a different timezone. You might ask "why does it matter?". Well, DST matters. In Fedora QA we have a weekly meeting that is tied to US local time. I created the event in Europe/Prague timezone, because that's my FAS setting. But here in Czech Republic the DST change occurs a week before US DST change occurs. Therefore the regular event is one hour off, this week.
I need to be able to change a timezone for a newly created events, so that I can tie them to a correct timezone.
As a workaround, I tried changing my timezone in FAS (so that I can delete the event and create a new one using US timezone), but it seems that FAS changes take a long time to take effect. The FAS OpenID request still shows Europe/Prague as the timezone being transmitted to Fedocal. Not a good workaround, still waiting...
0.3.0 has the possibility to choose a timezone when creating/editing a meeting.
So I guess this is a duplicate of https://fedorahosted.org/fedocal/ticket/28
Btw, 0.3.0 pre-release is at: https://apps.stg.fedoraproject.org/calendar/ testing is welcome :)
Great, thanks.
I created an event in America/New_York timezone yesterday, but it seems that the DST change is not reflected in the following week anyway. I'm not sure whether something is missing in iCal or what.
But that's not that important at the moment, I'll make the changes manually this time and we'll deal with that again in 6 months :)
hm that is interesting, although, the time are stored in the db in UTC, if you're not logged in, they are displayed in UTC (which does not change).
If you are logged in, the times are displayed in your local timezone, which if you have it set to !Europe/Prague in FAS will already have the time change. If you look one or two weeks back, do you see the time change?
I'm primarily concerned about the iCal contents at the moment. If the event is defined by UTC timestamps, then it obviously can't reflect DST, because UTC never changes. I imagined that if I define the event using America/New_York, then the event would display as i.e. 4 PM during winter and 5 PM during summer (as defined in America/New_York DST). I actually don't know whether iCal format supports this.
The iCal format would have to support not only 4 PM UTC -4 or 4 PM UTC -5 but also 4 PM New_York local time (pseudo syntax used)
I'm quite sure Google Calendar or Evolution can do that (if you define an event in 4 PM local time, it's always 4 PM, no matter whether it's winter or summer), but I can't say for sure that if you export an iCal file and import it elsewhere it will behave the same. Sounds reasonable, but I don't know.
If you store the event details in UTC in the database, then you most probably can't adjust the display on DST changes properly.
The iCal feed should provide only UTC date/time, I would expect the conversion to be on the client side.
Is this a wrong expectation?
With UTC only timestamps, you can't define an event that occurs in local time. New York is UTC-4 in summer and UTC-5 in winter (or similarly, you get the idea).
I tried to create a sample recurring event in Evolution and export ics. The iCal file seems to contain hundreds of definitions of DST changes for every available year (actually, that seems pretty lame, but maybe it's really part of the standard), like this:
{{{ BEGIN:VTIMEZONE TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Prague X-LIC-LOCATION:Europe/Prague .... .... BEGIN:STANDARD TZNAME:CET DTSTART:20121028T030000 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 END:STANDARD BEGIN:DAYLIGHT TZNAME:CEST DTSTART:20130331T020000 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 END:DAYLIGHT BEGIN:STANDARD TZNAME:CET DTSTART:20131027T030000 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 END:STANDARD .... .... END:VTIMEZONE }}}
After that the event is defined:
{{{ BEGIN:VEVENT UID:20131030T112621Z-26814-1000-1597-86@medusa DTSTAMP:20131026T102015Z DTSTART;TZID=/freeassociation.sourceforge.net/Tzfile/Europe/Prague: 20131031T160000 DTEND;TZID=/freeassociation.sourceforge.net/Tzfile/Europe/Prague: 20131031T170000 TRANSP:OPAQUE SEQUENCE:2 SUMMARY:foobar CLASS:PUBLIC RRULE:FREQ=WEEKLY;UNTIL=20131114;BYDAY=TH CREATED:20131030T112651Z LAST-MODIFIED:20131030T112651Z END:VEVENT }}}
Please notice that the event is defined in local time for Prague.
I assume that a combination of these two pieces of information ensure that a) the event is always displayed in the same time, no matter whether it's winter or summer b) if someone else with a different timezone (and different DST changes) displays this calendar, you can correctly compute the time for him and display in his local time.
Disclaimer: I don't really know anything about iCal. Just guessing.
This would imply storing the meeting time with timezone information, I'll have to think a bit more about this but since I need to do a partial re-write to handle location, I might include this in there.
What do you think of this: {{{ BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VTIMEZONE TZID:CET BEGIN:STANDARD DTSTART:20001029T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZNAME:CET TZOFFSETFROM:+0200 TZOFFSETTO:+0100 END:STANDARD BEGIN:DAYLIGHT DTSTART:20000326T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 TZNAME:CEST TZOFFSETFROM:+0100 TZOFFSETTO:+0200 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:20140107T174354Z-56901@carmine.pingoured.fr DTSTART;TZID=CET:20140108T060000 DTEND;TZID=CET:20140108T070000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:test END:VEVENT END:VCALENDAR }}} :)
That's certainly elegant. Will it work? :)
It might be a good idea to consult this with Evolution developers. There is probably a reason why they export hundreds of definitions of timezones for different years instead of creating a few recurring timezone definitions. Maybe the DST sometimes change, according to some political will or something? I'm not sure. It might also be interesting to see what Google Calendar exports as iCal.
Still, this looks good, in theory.
This is an ical output of the latest code of fedocal, so it works server side and from what I read it should work also client side.
I'll check for a recurring event if the time ever changes in March vs April and I can give you the ical output to check on your client (I'll check on mine as well).
So this is the output of the meeting above + another one, recurring
{{{ BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VTIMEZONE TZID:CET BEGIN:STANDARD DTSTART:20001029T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZNAME:CET TZOFFSETFROM:+0200 TZOFFSETTO:+0100 END:STANDARD BEGIN:DAYLIGHT DTSTART:20000326T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 TZNAME:CEST TZOFFSETFROM:+0100 TZOFFSETTO:+0200 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:20140110T121812Z-19717@carmine.pingoured.fr DTSTART;TZID=CET:20140108T060000 DTEND;TZID=CET:20140108T070000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:test END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-92311@carmine.pingoured.fr DTSTART;TZID=CET:20140113T180000 DTEND;TZID=CET:20140113T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-920@carmine.pingoured.fr DTSTART;TZID=CET:20140120T180000 DTEND;TZID=CET:20140120T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-50738@carmine.pingoured.fr DTSTART;TZID=CET:20140127T180000 DTEND;TZID=CET:20140127T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-95994@carmine.pingoured.fr DTSTART;TZID=CET:20140203T180000 DTEND;TZID=CET:20140203T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-29312@carmine.pingoured.fr DTSTART;TZID=CET:20140210T180000 DTEND;TZID=CET:20140210T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-29113@carmine.pingoured.fr DTSTART;TZID=CET:20140217T180000 DTEND;TZID=CET:20140217T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-82773@carmine.pingoured.fr DTSTART;TZID=CET:20140224T180000 DTEND;TZID=CET:20140224T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-12167@carmine.pingoured.fr DTSTART;TZID=CET:20140303T180000 DTEND;TZID=CET:20140303T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-54802@carmine.pingoured.fr DTSTART;TZID=CET:20140310T180000 DTEND;TZID=CET:20140310T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-89766@carmine.pingoured.fr DTSTART;TZID=CET:20140317T180000 DTEND;TZID=CET:20140317T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-20550@carmine.pingoured.fr DTSTART;TZID=CET:20140324T180000 DTEND;TZID=CET:20140324T190000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-88962@carmine.pingoured.fr DTSTART;TZID=CET:20140331T170000 DTEND;TZID=CET:20140331T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-19419@carmine.pingoured.fr DTSTART;TZID=CET:20140407T170000 DTEND;TZID=CET:20140407T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-59488@carmine.pingoured.fr DTSTART;TZID=CET:20140414T170000 DTEND;TZID=CET:20140414T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-39264@carmine.pingoured.fr DTSTART;TZID=CET:20140421T170000 DTEND;TZID=CET:20140421T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-96134@carmine.pingoured.fr DTSTART;TZID=CET:20140428T170000 DTEND;TZID=CET:20140428T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-49359@carmine.pingoured.fr DTSTART;TZID=CET:20140505T170000 DTEND;TZID=CET:20140505T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-57649@carmine.pingoured.fr DTSTART;TZID=CET:20140512T170000 DTEND;TZID=CET:20140512T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-15566@carmine.pingoured.fr DTSTART;TZID=CET:20140519T170000 DTEND;TZID=CET:20140519T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-47626@carmine.pingoured.fr DTSTART;TZID=CET:20140526T170000 DTEND;TZID=CET:20140526T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-33744@carmine.pingoured.fr DTSTART;TZID=CET:20140602T170000 DTEND;TZID=CET:20140602T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-13934@carmine.pingoured.fr DTSTART;TZID=CET:20140609T170000 DTEND;TZID=CET:20140609T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-22029@carmine.pingoured.fr DTSTART;TZID=CET:20140616T170000 DTEND;TZID=CET:20140616T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-23508@carmine.pingoured.fr DTSTART;TZID=CET:20140623T170000 DTEND;TZID=CET:20140623T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-5927@carmine.pingoured.fr DTSTART;TZID=CET:20140630T170000 DTEND;TZID=CET:20140630T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT BEGIN:VEVENT UID:20140110T121812Z-86194@carmine.pingoured.fr DTSTART;TZID=CET:20140707T170000 DTEND;TZID=CET:20140707T180000 DESCRIPTION:This is a recurring meeting that will happen every week for a while ORGANIZER:pingou\, SUMMARY:Recurring meeting END:VEVENT END:VCALENDAR }}}
If I read this right, the date/time start changes between summer and winter time, which should indicates it does what we want :)
The code for this part has been merged btw
Have you had the time to look at this? Beside the fact that the iteration is wrong, the timezone/DST handling seems to be fine.
Hmm, so, I imported this into Evolution and I see the recurring meeting to happen 18:00-19:00 until Mar 24 and 17:00-18:00 since Mar 31. Which is incorrect, because I would like to pin this even to Czech (or US or whatever) local time, i.e. 18:00-19:00 no matter whether there is summer or winter time.
The reason is that you defined that even to happen always in CET timezone, but since Mar 30 there is CE'''S'''T in the Czech Republic. (However, all countries might not switch to CEST at the same time, or at all).
So, I think there are two options: 1. Define the events since Mar 31 in CEST instead of CET. However, you still need a country selector to decide when the summer time change occurs. (That's why the timezone is defined for "Prague" in Evolution export, I guess). 2. Use the Evolution way - define all the timezone switches for reasonable past and future years for all countries included in the calendar. Then create a simple recurring event using this timezone definition.
The option 1. includes a short timezone definition, but massive duplication or items representing the recurring events. The option 2. includes a lot of timezone definition boilerplate, but every (even recurring) event is then a simple non-duplicated item. With lots of events in the calendar, option 2. seems more efficient and simpler and I begin to understand why it is implemented this way in Evolution.
I tried to create a simple recurring event in Google Calendar and the output is even simpler: {{{ BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:test X-WR-TIMEZONE:Europe/Prague X-WR-CALDESC: BEGIN:VTIMEZONE TZID:Europe/Prague X-LIC-LOCATION:Europe/Prague BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=Europe/Prague:20140115T160000 DTEND;TZID=Europe/Prague:20140115T170000 RRULE:FREQ=WEEKLY;UNTIL=20140514T140000Z;BYDAY=WE DTSTAMP:20140114T111808Z UID:tbi08k9stmmfac5jrbe3v8nl2g@google.com CREATED:20140114T111705Z DESCRIPTION: LAST-MODIFIED:20140114T111705Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:foobar TRANSP:OPAQUE END:VEVENT END:VCALENDAR }}} I think the timezone definition is simple for Czech Republic because we had no changes in our history as for when the summer time change occurs. But in some other countries it might be different (they might have changed the date of summer time change somewhere in their past). Still, there would be probably maximum of two or three DST definitions, which is much shorter than the Evolution-generated madness :-)
Because fedocal is not about perfect accuracy of events two decades ago, I think you should go for the simplest solution available. Currently it seems "Google Calendar" way - provide a single simple definition of DST change (as seen above) for every country available and include the necessary ones to ical export. The events can then use this definition as their TZID.
The list of DST dates and their respective countries could be searchable from the Internet, or it could be extracted from Evolution. By the way, isn't there some library module in Evolution that could be used for DST handling, so that you don't need to implement it from scratch?
Combining pytz, datetime and dateutil I should be able to get this correct, I thought I did but you're right it should not change over DST.
Note: at the top of the ical I produce the tz are already defined, thankfully this is automated ;-)
Looks like I managed :)
{{{ BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VTIMEZONE TZID:CET BEGIN:STANDARD DTSTART:20001029T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZNAME:CET TZOFFSETFROM:+0200 TZOFFSETTO:+0100 END:STANDARD BEGIN:DAYLIGHT DTSTART:20000326T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 TZNAME:CEST TZOFFSETFROM:+0100 TZOFFSETTO:+0200 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:20140114T132456Z-22925@carmine.pingoured.fr DTSTART;TZID=CET:20140324T040000 DTEND;TZID=CET:20140324T050000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:rec END:VEVENT BEGIN:VEVENT UID:20140114T132456Z-73155@carmine.pingoured.fr DTSTART;TZID=CET:20140331T040000 DTEND;TZID=CET:20140331T050000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:rec END:VEVENT BEGIN:VEVENT UID:20140114T132456Z-9183@carmine.pingoured.fr DTSTART;TZID=CET:20140407T040000 DTEND;TZID=CET:20140407T050000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:rec END:VEVENT BEGIN:VEVENT UID:20140114T132456Z-40485@carmine.pingoured.fr DTSTART;TZID=CET:20140414T040000 DTEND;TZID=CET:20140414T050000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:rec END:VEVENT BEGIN:VEVENT UID:20140114T132456Z-54280@carmine.pingoured.fr DTSTART;TZID=CET:20140421T040000 DTEND;TZID=CET:20140421T050000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:rec END:VEVENT BEGIN:VEVENT UID:20140114T132456Z-67057@carmine.pingoured.fr DTSTART;TZID=CET:20140428T040000 DTEND;TZID=CET:20140428T050000 DESCRIPTION: ORGANIZER:pingou\, SUMMARY:rec END:VEVENT END:VCALENDAR }}}
The problem was basically in the way I was setting the timezone (ie before putting the date and time together while it should be done before putting the timezone information).
Ok all the changes made (even on tickets that are not yet closed) are on the dev instance I just updated: http://fedocal.dev.fedoraproject.org
It would be awesome if you could have a look at it and see where it breaks :)
Thanks!
I don't understand it, the output in comment 17 looks the same as output in comment 12, but the latter one really shows a fixed local time across DST change in Evolution. I'm baffled.
I wonder, why do you duplicate the events instead of using RRULE as in Google output?
I'll try the test instance, thanks.
Replying to [comment:20 kparal]:
The development instance seems to use RRULE.
I tested it and it seems to work well for this issue.
There is no output in comment 17, the one in 16 is your then there is the one in 18 which is the new one with the adjustments.
That was https://fedorahosted.org/fedocal/ticket/85
I'll try the test instance, thanks. I tested it and it seems to work well for this issue.
Awesome! Feel free to bug it and let me know if you have any problem with it.
Should we close this bug now?
Replying to [comment:22 pingou]:
Replying to [comment:20 kparal]: I don't understand it, the output in comment 17 looks the same as output in comment 12, but the latter one really shows a fixed local time across DST change in Evolution. I'm baffled. There is no output in comment 17, the one in 16 is your then there is the one in 18 which is the new one with the adjustments.
Weeell, I meant I don't really see what has changed between https://fedorahosted.org/fedocal/ticket/73#comment:12 and https://fedorahosted.org/fedocal/ticket/73#comment:17
The latter one works, the former one does not.
Yes, I think we can.
The times themselves have changed if you look at the last meetings on the list.
But since it works, let's close as fixed :)
Oh, I see it know. Thanks.
Login to comment on this ticket.