import of timezones wrong with WCAP server (litmus test 3050)

RESOLVED INVALID

Status

Calendar
Import and Export
RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: Andreas Huber, Unassigned)

Tracking

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.4) Gecko/20070509 Camino/1.5 (MultiLang)
Build Identifier: 2007101603

When running litmus test 3050, the dates of Perth and New York are wrong when importing an ics-file to the WCAP-server. When importing to a local server, New Your is OK, but Perth is still wrong.

Using Sunbird 0.7rc2 with 'de' locale running on Mac OS X 10.4/Intel

Reproducible: Always

Steps to Reproduce:
Run litmus test 3050: https://litmus.mozilla.org/show_test.cgi?id=3050
Actual Results:  
9am Perth should be 1am, shows as 2am
9am New York should be 3pm, shows as 10am

Using local calendar, New York is OK, but Perth still wrong

Expected Results:  
9am Perth should be 1am, shows as 2am
9am New York should be 3pm, shows as 10am

Using local calendar, New York is OK, but Perth still wrong

Comment 1

10 years ago
Problem with WCAP is that it doesn't support foreign timezones. You cannot store definitions nor use different ones than the server supports. sd-calendar.staroffice.de doesn't support timezone "US/Eastern" thus the provider falls back storing in the user's standard one, e.g. "Europe/Paris". Moreover even though "Australia/Perth" is supported, the timezone definition of the litmus case is different. It has no RRULE defined whereas sd-calendar's definition looks like:

BEGIN:VTIMEZONE
TZID:Australia/Perth
X-S1CS-TZID-ALIAS:W. Australia Standard Time
BEGIN:STANDARD
DTSTART:19970101T000000
TZOFFSETFROM:+0900
TZOFFSETTO:+0800
TZNAME:CSST
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20061203T020000
TZOFFSETFROM:+0800
TZOFFSETTO:+0900
TZNAME:CSDT
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:DAYLIGHT
END:VTIMEZONE

I don't think the test case makes sense against WCAP servers since foreign timezones are not supported.

Comment 2

10 years ago
Can't fix.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.