Calendar Entries- always wrong time on some computers

[area]

The resetting of the timezone is not permanent - the next time a user accesses Zimbra from certain PCs the TZ is changed back to GMT-08.00.

I thought that the problem was from external PCs with the TZ set incorrectly (ie: to GMT-08.00) but this is not the case.

It seems that all the PCs in the internal LAN (a 192.168.x.x subnet) cause the TZ to be reset to GMT-08.00 as soon as the user logs on to Zimbra - this happens with IE and Firefox. All the PCs have their TZ set to AEST (GMT+10.00) according to Control Panel's 'Date & Time' applet - so I am perplexed as to what setting on these PCs causes Zimbra to change its TZ.

Logging onto Zimbra from an external PC (also with the TZ set to GMT+10.00) will case the Zimbra TZ to be changed to GMT+10.00

The internal PCs access the Zimbra PC directly and not through a proxy, they all run Windows XP with roaming profiles and are part of a Windows 2003 AD domain.

So how does Zimbra determine the TZ of the client?

[KevinH]

There is code in the Web Client that will update the TZ when it detects a change. It's may be this code is incorrectly detecting change. I put the *guts* of that code below. You'll notice the comment about Firefox. One thing we could do is add some debug to this method which would print out what it detects and when it updates.

	
/**
 * One problem with firefox, is if the timezone on the machine changes,
 * the browser isn't updated. You have to restart firefox for it to get the 
 * new machine timezone.
 */
ZmTimezones.guessMachineTimezone = 
function() {
	var dec1 = new Date(2005, 12, 1, 0, 0, 0);
	var jun1 = new Date(2005, 6, 1, 0, 0, 0);
	var dec1offset = dec1.getTimezoneOffset();
	var jun1offset = jun1.getTimezoneOffset();
	var pos = ((dec1.getHours() - dec1.getUTCHours()) > 0);
	if (!pos) {
		dec1offset = dec1offset * -1;
		jun1offset = jun1offset * -1;
	}
	var tz = null;
	// if the offset for jun is the same as the offset in december,
	// then we have a timezone that doesn't deal with daylight savings.
	if (jun1offset == dec1offset) {
		var list = ZmTimezones.ruleLists.noDSTList;
 		for (var i = 0; i < list.length ; ++i ) {
			if (list[i].stdOffset == jun1offset) {
				tz = list[i];
				break;
			}
		}
	} else {
		// we need to find a rule that matches both offsets
		var list = ZmTimezones.ruleLists.DSTList;
		var dst = Math.max(dec1offset, jun1offset);
		var std = Math.min(dec1offset, jun1offset);
		var rule;
 		for (var i = 0; i < list.length ; ++i ) {
			rule = list[i];
			if (rule.stdOffset == std && rule.dstOffset == dst) {
				if (ZmTimezones._compareRules(rule, std, dst, pos)) {
					tz = rule;
					break;
				}
			}
		}
	}
	return tz ? tz.name : ZmTimezones._FALLBACK;
};

[area]

Thanks for that Kevin.

I started making up a test web page with this code but it refers to some predefined Zimbra objects (eg: ZmTimezones.*) - I found the definitions of ZmTimezones from one of the JS files but I still need the definitions for the ZmMsg.TZF_* to complete the test page so I gave up...

I'm happy to help out debugging this - I could try adding some alerts to the "guessMachineTimezone" function in the file ZimbraMail_all.js and then gzip it to ZimbraMail_all.js.zgz - is there a better way to generate ZimbraMail_all.js.zgz from ZimbraMail_all.js? Is this a reasonable approach or am I wasting my time?

[area]

I added two alerts to the "guessMachineTimezone" function :

if (rule.stdOffset == std && rule.dstOffset == dst) {
alert("match found for "+rule.name+" - calling _compareRules...");
if (ZmTimezones._compareRules(rule, std, dst, pos)) {
alert("_compareRules returned true!");

When I login from a remote PC, there are 4 alerts:

match found for (GMT+10.00) Canberra / Melbourne / Sydney
_compareRules returned true!
match found for (GMT+10.00) Canberra / Melbourne / Sydney
_compareRules returned true!

and the timezone on a new appointment is set to Canberra, Sydney.

When I login from an internal PC, there are 6 alerts:

match found for (GMT+10.00) Canberra / Melbourne / Sydney
match found for (GMT+10.00) Hobart
match found for (GMT+10.00) Vladivostok
match found for (GMT+10.00) Canberra / Melbourne / Sydney
match found for (GMT+10.00) Hobart
match found for (GMT+10.00) Vladivostok

and the timezone on a new appointment is set to Pacific Time (US & Canada).

So perhaps the ZmTimezones.ruleLists.DSTList is different between the two PCs or the variables 'dst' or 'std' are different - I'll do some more testing later.

[area]

I added one more alert before the for loop:

alert("checking "+list.length+" rules; std="+std+"; dst="+dst)

and from both the remote PC and the internal PC, the same message is displayed:

checking 29 rules; std=600; dst=660

Hope this helps - off to do some "real" work...

[KevinH]

Must be something with compare rules... Maybe we need to add some alerts in there. Can you verify you cleared the cache before these tests to make sure the TZ lists were identical. Also may be a good idea to restart Tomcat just to be sure as we cache the properties files that generate the TZ lists. This way we know both browsers are getting the same code and are up-to-date.