Recurring Events and Daylight Savings

[jshtimsj]

After daylight savings we've noticed that recurring events in Zimbra's calendar are off by one hour. Any suggestions on how to fix this? We're running Release 6.0.7_GA_2473.RHEL5_64_20100616202447 CentOS5_64 NETWORK edition.

Thanks

[soxfan]

I am running ZCS 6.0.10 (FOSS) and I am not seeing this problem. I do seem to remember this coming up in the past, but I think it was in the version 5, or maybe even version 4, days. Are you sure the time on your server (and clients) is correct, and you have the right time-zone set on your accounts in Zimbra?

[jshtimsj]

Yes, the date, time and timezone are all correct on the server and our workstations as well as in the CoS in Zimbra. Non-recurring events are working fine. How can recurring events be in a different timezone than non-recurring ones?

[soxfan]

Seems like all your settings are correct. Have you checked bugzilla to see if there are any bugs concerning DST that may have been fixed since 6.0.7? Is it happening with all recurring events or just some? Were any of these events migrated over from another system?

Sorry, wish I had an answer for you, but like I said it is working fine on 6.0.10 here. So it seems like it is either a configuration or version issue.

[jshtimsj]

I don't see any bugs related to this. Perhaps I'm missing them.

Its all recurring events, however we don't have many users using the Calendar portion of Zimbra at the moment. Most if not all of these get added from emails from a different calendar application (eGroupware).

[jshtimsj]

Any other suggestions on how to go about resolving this? Upgrading to 6.0.10, or will that just preserve the incorrect events? Does Zimbra have any utilties for fixing timezone errors? Why would migrating events from a different system matter? Is there a known bug with this?

Thanks

[i2ambler]

Im running 6.0.7 and am having this problem as well.. Daylight Savings just hit - and now we are receiving reports of appointments being an hour off. Is there any way to fix this other than upgrading??

[stodavr]

Had the same problem (Mac Firefox). After daylight savings, default time zone for making appointments got switched to -5:00 from -6:00 (the only way to tell is by turning on timezone display as an option).

For what it's worth, only Firefox had this problem in using Zimbra. When I tried using Safari, things worked normally.

[soxfan]

I find that the Zimbra bugzilla can be difficult to search sometimes. I couldn't find anything related to a DST issue either. I did see one fix go through in 6.0.8 mentioned in the release notes related to daylight savings, but it specifically referred to Chile's time change. Maybe they fixed one DST issue and it fixed others that hadn't even been reported as well.

You both seem to be running the NE version. Have you tried opening a trouble ticket?

[bquinata]

If possible take a look at the original raw data. For calendar events, right click on the event and go to "Show Original" either under the "Series" or "Instance".

Specifically, look for DTSTART;TZID and DTEND;TZID between events that are "displaying" correctly and those which are not.

Here are my outputs from two difference calendar events:

#1
DTSTART;TZID="America/New_York":20110125T120000
DTEND;TZID="America/New_York":20110125T130000

#2
DTSTART;TZID="America/Phoenix":20110125T100000
DTEND;TZID="America/Phoenix":20110125T103000

#1 event is using NY as its timezone and before daylights savings occured at 9AM(Phoenix time) , #2 is using Phoenix at its time zone and occurs at 10AM(Phoenix time) before daylight savings.

After daylight savings took effect, #1 moved to 10AM(Phoenix time) and #2 stayed put. Arizona does not use daylight savings and is the reason why #2 did not change.

If your event only has DTSTART and DTEND, then timezone is not declared. The date value will either be "floating" or based on UTC.

An example of a floating date value: 20110125T103000. Where as a date value based on UTC will have a Z appended to the end: 20110125T103000Z

I hope this helps.

Good Luck.

REFERENCE:http://www.ietf.org/rfc/rfc2445.txt