If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

CalIDateTime.getInTimezone(x) loses timezone property

RESOLVED WORKSFORME

Status

Calendar
Internal Components
RESOLVED WORKSFORME
11 years ago
11 years ago

People

(Reporter: Mark Swanson, Unassigned)

Tracking

Details

(Reporter)

Description

11 years ago
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

11 years ago
<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?
(Reporter)

Comment 3

11 years ago
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. :-(

Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.