User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20070309 Firefox/220.127.116.11 Build Identifier: Lightning 0.3.1 When you convert a CalIDateTime using getInTimezone( <some valid tzid> ) the resulting CalIDateTime.timezone property is undefined. Reproducible: Always Steps to Reproduce: 1. create a CalIDateTime 2. derive a new one using getInTimezone(calendarDefaultTimezone()); 3. examine the new object timezone property - it's undefined. Actual Results: undefined timezone Expected Results: timezone should be the value of calendarDefaultTimezone()
<LightSpeed> It's weird - I think it may be a bug - when I toString() I see the timezone, but when I print the timezone property it's undefined. <ssitter> how do you access timezone? <LightSpeed> newCalIDateTime.timzone <ctalbert> I think this is due to the last minute 0.3.1 tiemzone fix. When we overloaded nsACString, I think we broke XPConnect because it doesn't know what in the world a calTzid is. But, it can still drop out a string because underneath the covers the tzid is a string.
(In reply to comment #1) > <LightSpeed> newCalIDateTime.timzone Is that a typo in copying the code, or does the code have that typo? (timzone instead of timezone) > <ctalbert> I think this is due to the last minute 0.3.1 tiemzone fix. When we > overloaded nsACString, I think we broke XPConnect because it doesn't know what > in the world a calTzid is. But, it can still drop out a string because > underneath the covers the tzid is a string. If so, this should work on current builds. Does it?
Typo in the code. I think I did not understand the requirement to convert to UTC first and my timezone mistake was just a side effect. I'm sorry for the noise. :-(