Closed
Bug 400289
Opened 17 years ago
Closed 17 years ago
import of timezones wrong with WCAP server (litmus test 3050)
Categories
(Calendar :: Import and Export, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: andunix, Unassigned)
Details
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•17 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•17 years ago
|
||
Can't fix.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•