375738 - CalIDateTime.getInTimezone(x) loses timezone property

Status: RESOLVED WORKSFORME

(Calendar :: Internal Components, defect)

Description

[Mark Swanson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
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()

Comment 1

[Stefan Sitter [:ssitter]]

<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.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

(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?

Comment 3

[Mark Swanson]

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. :-(