344682 - tzdata.c using non-standard TZID data

Status: RESOLVED DUPLICATE of bug 327602

(Calendar :: General, defect)

Description

[Tom]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.4) Gecko/20060603 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.4) Gecko/20060603 Firefox/1.5.0.4

This file prepends /mozilla.org/ to all of the timezone data which is not part of the ical standard.  Trying to use/export .ics files created under Sunbird can cause errors and/or not update properly.  Case in point Sunbird will not work properly with Communigate Pro as the webdav/ical server.

I have removed all /mozilla.org/ tags from the tzdata.c file and recompiled Sunbird on a FreeBSD 6.1 box and the errors have stopped completely.  The files on the server are also getting updated properly.

Reproducible: Always

Steps to Reproduce:
1. Export a calendar and look at DTSTART and DTEND
2. Use Communigate Pro and try to update a calendar
3.

Actual Results:  
You will notice that /mozilla.org/ is prepended to DTSTART and DTEND breaking the ical standard.  Using Communigate Pro you will receive Error Number: 0x0 with Description: Publishing the calendar file failed Status code : 500: Illegal Calendar data format

Expected Results:  
The calendar should be updated without error.

Comment 1

[Tom]

Attachment: tzdata.c file with removed /mozilla.org/ tags

Comment 2

[Joey Minta]

I'm reading RFC2445 which says "Note: The specification of a global time zone registry is not
        addressed by this document and is left for future study.
        However, implementers may find the Olson time zone database [TZ]
        a useful reference. It is an informal, public-domain collection
        of time zone information, which is currently being maintained by
        volunteer Internet participants, and is used in several
        operating systems. This database contains current and historical
        time zone information for a wide variety of locations around the
        globe; it provides a time zone identifier for every unique time
        zone rule set in actual use since 1970, with historical data
        going back to the introduction of standard time.

   Interoperability between two calendaring and scheduling applications,
   especially for recurring events, to-dos or journal entries, is
   dependent on the ability to capture and convey date and time
   information in an unambiguous format. The specification of current
   time zone information is integral to this behavior."

Furthermore, considering that the iCalendar standarrd then goes on to give an example of
  TZID:US--Fictitious-Eastern
I think it's pretty clear that it is each individual app's responsibility to handle interpretting arbitrary VTIMEZONE ids and presenting them properly to the user.  What would CommunigatePro do with a timezone such as US--Ficticious-Eastern, which the spec explicitly says is valid?

I suggest this is a bug in Communigate Pro and this bug should be resolved invalid.

Comment 3

[Matthew (lilmatt) Willis]

*** This bug has been marked as a duplicate of 327602 ***

Comment 4

[daniele.tiles]

Hi,
as a developer of another Calendar App, however, I'd like to understand how should I treat a Mozilla Sunbird TZID...where I can find the informations about the TimeZone? If I subscribe a Mozilla Sunbird calendar, I don't understand how to convert from the TZID present in your iCalendar into the one I've set in my Calendar App...any documentation?
Wouldn't have been easier to use the TZID?

Comment 5

[daniele.tiles]

>Wouldn't have been easier to use the TZID?

...sorry, I meant the Olson DB...

Comment 6

[Joey Minta]

(In reply to comment #4)
> Hi,
> as a developer of another Calendar App, however, I'd like to understand how
> should I treat a Mozilla Sunbird TZID...where I can find the informations about
> the TimeZone? If I subscribe a Mozilla Sunbird calendar, I don't understand how
> to convert from the TZID present in your iCalendar into the one I've set in my
> Calendar App...any documentation?
> Wouldn't have been easier to use the TZID?
> 
That's what the VTIMEZONE we (are required to) include tells you.  You should look at the offsets, and dates of daylight savings switch and compare them with your own database.

I'll note that mapping external timezone definitions into a local database is a problem that all calendar apps struggle with, but one which you're required to address.  We have several open bugs on the conversion ourselves, so be warned that this mapping isn't trivial.