US DST Change support in Zimbra 3.1.4

[kiwicmc]

Most states in the US and all provinces in Canada are about to change the time that Daylight Savings comes into effect.

http://www.microsoft.com/windows/timezone/dst2007.mspx

How can I check that the Zimbra timezone rules are correct for this, or how can I self modify without upgrading to 4.0?

After a little more investigation, I think what will happen is this.

The timezone calculation is done on the Web Client and therefore it is the responsibility of the client platform to set the rules. Therefore the above url from MS has the answers for Windows platforms.

If there is anything happening on the server then as long as we are running Java 1.5-06 (which is what ships with Zim 3.1.4) then the rules here are also correct.

http://java.sun.com/developer/techni...es/Intl/USDST/

I'll have a prowl through the LDAP entries to verify that there is not anything else that may trip things up.

OK I may well be incorrect - there are timezone rules being stored in the Zimbra LDAP config

This is what is loaded for Zimbra 3.1.4:

# (GMT-08.00) Pacific Time (US & Canada) / Tijuana
# (supports Daylight Savings Time)
dn: cn=(GMT-08.00) Pacific Time (US & Canada) / Tijuana,cn=timezones,cn=config,cn=zimbra
objectclass: zimbraTimeZone
cn: (GMT-08.00) Pacific Time (US & Canada) / Tijuana
zimbraTimeZoneStandardDtStart: 16010101T020000
zimbraTimeZoneStandardOffset: -0800
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
zimbraTimeZoneDaylightDtStart: 16010101T020000
zimbraTimeZoneDaylightOffset: -0700
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU

So this says that Daylight Savings starts on the 1st Sunday in April. Whereas it should now say Daylight Savings starts on the second Sunday in March. And ends the last Sunday in October, whereas it should now be the 1st Sunday in November.

On a Zimbra 4.0.5 release the equivalent loaded timezone is (from /opt/zimbra/conf/zimbra.ldif):

# (GMT-08.00) Pacific Time (US & Canada) / Tijuana
# (supports Daylight Savings Time)
dn: cn=(GMT-08.00) Pacific Time (US & Canada) / Tijuana,cn=timezones,cn=config,cn=zimbra
objectclass: zimbraTimeZone
cn: (GMT-08.00) Pacific Time (US & Canada) / Tijuana
zimbraTimeZoneStandardDtStart: 16010101T020000
zimbraTimeZoneStandardOffset: -0800
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
zimbraTimeZoneDaylightDtStart: 16010101T020000
zimbraTimeZoneDaylightOffset: -0700
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU


OK, so this seems like a pretty serious problem, I'll work out a LDAP update script and post. If someone from Zimbra could confirm these findings I'd appreciate it.

Regards,
Chris

[andyc]

Unfortunately, the web client has code that contains a table of the same timezone information that is stored in LDAP on the server. You would also need to adjust that code to match, which is not the easiest thing to do.

For performance, we "jam" all of the JavaScript source files together into a few big bundles that are loaded by the client. And those files are then gzipped to minimize the download size. So you'd need to find the timezone information in your system, modify it in the jammed files and then re-gzip them.

In short, upgrading would be a much better option.

[kiwicmc]

Thanks for the reply Andy. However you appear to still have the issue in the current release of Zimbra (4.0.5). Not only is it pushing it to have every Zimbra install upgrade to 4.5 by March 11, but surely the calendar values for meetings that take place after March 11 may appear incorrect to viewers from other timezones?

If I look in the source of the EDISON branch the ldif file still has the same values as discussed above.

https://svn.sourceforge.net/svnroot/...ap/zimbra.ldif

In 4.5 the ldif file has been gutted of timezone entries so obviously things are working differently there.

It looks like you've moved/renamed the Javascript file that used to contain the values on the client, so I could not check that. This is the file in the 3.1.4 branch.

ZimbraWebClient\WebRoot\js\zimbraMail\prefs\model\ ZmTimeZones.js

We actually roll our own client so I can make the fixes for myself here.

C

[kiwicmc]

Aren't they always ...

Time-Zone Changes for Western Australia Begin December 3, 2006
AWDT - Australian Western Daylight Time (experimentally in use 2006 - 2009). will use the same rules as NSW, Vic and SA

[kiwicmc]

It seems that the code in ZmTimeZones.js is there to get a timezone value that will match the list held on the server. It takes its settings from dates in 2005. Therefore we can assume that this logic will still be correct, even though timezones have changed in 2006/2007.

Is there something else I am missing?

C

[kiwicmc]

I have confirmed the problem in Zimbra 4.0.5 and confirmed that the fixes below fix the issue.

From a Zimbra client with browser platform in NZDT. In Calendar I created an appointment. I set the timezone to US/Central, I created a meeting on the 10th March 2007 at 3pm - it showed in my NZDT calendar as 10am - Correct.
Next I created a meeting on the 11th March 2007 at 3pm (US/Central) it showed in my NZDT calendar as 10am - INCORRECT

After the US Central timezone was modified and the experiment repeated the second appointment was shown as 9am - CORRECT

WARNING! I'm not responsible for anyone screwing their Zimbra installation. If you don’t know what you're doing, don’t do it. Or make a call to Zimbra support ...

The following changes Zimbra DST rules for:

All of the United States except:

Arizona, Hawaii, Puerto Rico, the U.S. Virgin Islands, and American Samoa

Indiana is a weird case and those folk located there can make up their own minds what TZ to modify or observe ....

The Navajo Nation located in Arizona appears to observe daylight savings, I have no idea what TZ you would choose.

Canada except for most of Saskatchewan observes DST

Atlantic Timezone - It appears that the Nova Scotia in the Atlantic TZ observes daylight savings, but this was not implemented in Zimbra.

Western Australia - made the decision to support DST in November with cut over in December - thanks for the warning guys.

First find your LDAP admin DN and password:

[zimbra@cmp conf]$ zmlocalconfig -s | grep zimbra_ldap 
zimbra_ldap_password = kiyC9CQS
zimbra_ldap_userdn = uid=zimbra,cn=admins,cn=zimbra

Grab the lines at the bottom of this post and save it as modentry.ldif in /tmp

Next modify your LDAP server (note the substituted DN and password):

ldapmodify -H ldap://ldaphost.example.com -x -D "uid=zimbra,cn=admins,cn=zimbra" -f /tmp/modentry.ldif -w kiyC9CQS

Restart Zimbra

#### Cut below here
version: 1

# Modify (GMT-09.00) Alaska
dn: cn=(GMT-09.00) Alaska,cn=timezones,cn=config,cn=zimbra
changetype: modify
replace: zimbraTimeZoneStandardRRule
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
-
replace: zimbraTimeZoneDaylightRRule
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU

# (GMT-08.00) Pacific Time (US & Canada) / Tijuana
# (supports Daylight Savings Time)
dn: cn=(GMT-08.00) Pacific Time (US & Canada) / Tijuana,cn=timezones,cn=config,cn=zimbra
changetype: modify
replace: zimbraTimeZoneStandardRRule
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
-
replace: zimbraTimeZoneDaylightRRule
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU

# (GMT-07.00) Mountain Time (US & Canada)
# (supports Daylight Savings Time)
dn: cn=(GMT-07.00) Mountain Time (US & Canada),cn=timezones,cn=config,cn=zimbra
changetype: modify
replace: zimbraTimeZoneStandardRRule
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
-
replace: zimbraTimeZoneDaylightRRule
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU

# (GMT-06.00) Central Time (US & Canada)
# (supports Daylight Savings Time)
dn: cn=(GMT-06.00) Central Time (US & Canada),cn=timezones,cn=config,cn=zimbra
changetype: modify
replace: zimbraTimeZoneStandardRRule
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
-
replace: zimbraTimeZoneDaylightRRule
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU

# (GMT-05.00) Eastern Time (US & Canada)
# (supports Daylight Savings Time)
dn: cn=(GMT-05.00) Eastern Time (US & Canada),cn=timezones,cn=config,cn=zimbra
changetype: modify
replace: zimbraTimeZoneStandardRRule
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
-
replace: zimbraTimeZoneDaylightRRule
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU

# (GMT-04.00) Atlantic Time (Canada)
dn: cn=(GMT-04.00) Atlantic Time (Canada),cn=timezones,cn=config,cn=zimbra
changetype: modify
replace: zimbraTimeZoneStandardDtStart
zimbraTimeZoneStandardDtStart: 16010101T020000
-
add: zimbraTimeZoneStandardRRule
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU
-
replace: zimbraTimeZoneDaylightDtStart
zimbraTimeZoneDaylightDtStart: 16010101T020000
-
replace: zimbraTimeZoneDaylightOffset
zimbraTimeZoneDaylightOffset: -0400
-
add: zimbraTimeZoneDaylightRRule
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU

# (GMT+08.00) Perth
dn: cn=(GMT\+08.00) Perth,cn=timezones,cn=config,cn=zimbra
changetype: modify
replace: zimbraTimeZoneStandardDtStart
zimbraTimeZoneStandardDtStart: 16010101T030000
-
add: zimbraTimeZoneStandardRRule
zimbraTimeZoneStandardRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU
-
replace: zimbraTimeZoneDaylightDtStart
zimbraTimeZoneDaylightDtStart: 16010101T020000
-
replace: zimbraTimeZoneDaylightOffset
zimbraTimeZoneDaylightOffset: +0900
-
add: zimbraTimeZoneDaylightRRule
zimbraTimeZoneDaylightRRule: FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
### End of file

[kiwicmc]

So in a previous post I assumed that a date check in 2005 would exhibit the daylight savings rule that was in effect at that time. Indeed running Zimbra on a Mac with FF this was the case. However on a Windows machine (Vista and a fully patched XP) this is NOT the case. Suddenly Javascript dates around 2005 exhibit the daylight savings shift that is only surrent for 2007 and beyond.

Therefore a change in the WebClient code is required for v3.1.4 at least.

C