Closed Bug 407801 Opened 17 years ago Closed 6 years ago

Assert failed: timezone not available in calUtil.js

Categories

(Calendar :: Internal Components, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: aryx, Unassigned)

Details

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20071210 Calendar/0.8pre

On startup, I get really many of these error messages in the error console:
Error: Assert failed: timezone not available: /Mozilla.org/BasicTimezones/GMT
1: ASSERT
2: newDateTime
3: 
4: 
5: getItems

Source File: file:///F:/Software/Buero/Kalender/Sunbird%20Branch/js/calUtils.js
Line: 781

I tried to reproduce by importing non-storage calendars in a fresh profile, but had no success. (1 local, 2 remote calendars, 15 storage calendars)
Yeah, this log is quit annoying if you use a profile that contains events with foreign timezone. The Error Console is overcrowded with that messages. 

Would it be possible to log the error only once per timezone? 

It probably also makes more sense to log directly to the console instead of using the ASSERT function. Currently you just get the line number and link of the ASSERT function. Logging directly to the console would give the line number and link of the original error location.
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
Version: Mozilla 1.8 Branch → unspecified
Did bug 402518 fix this in the latest nightly?
I think archaeopteryx's problem is that the referenced timezones are not yet available anymore, so I assume they've been in a former calendar version but haven't been upgraded to current TZIDs. I haven't seen any migration code in storage nor calICSService.cpp / calTimezoneService.cpp that maps "/Mozilla.org/BasicTimezones/" to a current TZID. Bug 402518 won't fix that.
I don't know what TZIDs are really missing (is it only GMT?), but if we don't go for a tz database approach soon, a quick fix would alias it in <http://mxr.mozilla.org/mozilla1.8/source/calendar/base/src/calTimezoneService.cpp#176>.
Archaeopteryx, do you still see this happening?
Yes, I am still seeing this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13pre) Gecko/20080220 Calendar/0.8pre
Attached file errors from the JS console —
I'm still seeing this, on Thunderbird 2 / Lightning 0.9 (release, from AMO).  Attached is the errors from my JS console.

I'm using this with Zimbra; grepping through the .ics Zimbra feeds me (curl) for TZID: I get:
TZID:(GMT-08.00) Pacific Time (US & Canada)
TZID:America/Los_Angeles
TZID:/mozilla.org/20071231_1/America/Los_Angeles
TZID:/mozilla.org/20070129_1/America/Los_Angeles
TZID:US/Pacific

Sample event: (I'm not sure which client this was made with)
BEGIN:VEVENT
UID:1fc264a5-7d6b-48ea-822f-2dc0ab08c987
SUMMARY:Insert Summary Here
DESCRIPTION:I'm not telling\n\n
LOCATION:Some Place
ATTENDEE;CN=Common Name;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE
 :mailto:person@example.com
X-MOZ-GENERATION:1
ORGANIZER;CN=Organizer:mailto:somebody@example.com
DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080905T150000
DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)":20080905T160000
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
DTSTAMP:20080902T220204Z
SEQUENCE:0
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-PT5M
DESCRIPTION:Mozilla Alarm: Insert Summary Here
X-MOZ-LASTACK:20080905T215506Z
END:VALARM
END:VEVENT
Using such ics fragments (with TZID="(GMT-08.00) Pacific Time (US & Canada)" and faked VTIMEZONE) works well for me: Both coming per ics, and migrating as foreign timezone to storage. No errors, thus I don't think those events are really causing that.
My question form comment #3 still stands: There is no migration code "/Mozilla.org/BasicTimezones/". It would be good to know what timezones have been scoped using that prefix.
I think we will not add migration code for those old TZIDs anymore.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: