-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yeah, I''ve put in this fix for now, but in general this is something
that will have to be worked into the parser. I''m in the process of
moving to Switzerland from Colorado so things are a bit chaotic, but
property parameters and correct support of nested components are at the
top of the list. (Someone was talking about working on property
parameters.... any progress on that? I don''t remember who it was.)
I think I''ve just about got my textdrive account setup for public
access
to the subversion repository. Once its ready I''ll post to the list so
you guys can work of trunk directly. I''m also working on a collaboa
installation so people can post tickets for feature requests, bugs etc...
If a few people could post sample calendars from whichever programs they
are using to the list that would be helpful for now. It would be great
to put together a suite of test calendars from various apps which can be
used for both unit testing as well as showing functionality with the
sample applications.
- - Jeff
Brad Ediger wrote:> Eric,
> I just patched that last week -- Jeff says it''s in trunk. My copy
> ignores the timezone, too, so it isn''t the best workaround, but it
> parses. I guess we need to look at a long-term solution, right?
>
> --
> Brad Ediger
> Madriska Media Group
> www.madriska.com
> 866-334-4377 toll-free
> 815-301-3105 fax
>
>
> On Aug 29, 2005, at 3:30 PM, Eric Bardes wrote:
>
>> Hello everyone, I made a local modification to my copy of
>> Icalendar::Parser. I''m using Sunbird to maintain my calendar
and it
>> creates a timezone block that causes it to prematurely exit. The
>> problem is that the BEGIN:VTIMEZONE works okay, but the
>> BEGIN:DAYLIGHT and BEGIN:STANDARD do not, so the END:DAYLIGHT and
>> END:STANDARD are inadvertently matched with BEGIN:VTIMEZONE and
>> BEGIN:VCALENDAR, causing it to exit.
>>
>> My knee-jerk workaround, was to insert the else clause into the case
>> statement that managed the "BEGIN" clause.
>>
>> when "VTIMEZONE"
>> component.timezones << parse_component(Timezone.new)
>> when "VALARM"
>> component.alarms << parse_component(Alarm.new)
>> else
>> parse_component(component)
>> end
>> else # If its not a component then it should be a property
>>
>> I''ll be the first to agree that this isn''t
what''s right for
>> icalendar. My work-around throws out timezone information, which
>> limits it usefulness to everything but the local timezone and assumes
>> all the input is in the local timezone of the current process.
>>
>> A better solution would include adding code that checks that each
>> ''END'' matches it''s corresponding
''BEGIN''
>>
>> --
>> Cheers,
>> Eric Bardes
>> _______________________________________________
>> icalendar-devel mailing list
>> icalendar-devel@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/icalendar-devel
>>
>
> _______________________________________________
> icalendar-devel mailing list
> icalendar-devel@rubyforge.org
> http://rubyforge.org/mailman/listinfo/icalendar-devel
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFDFg1SABKrmewgEfIRAnTnAKDcbB1Ew5JV8i5s2zF25XWFq5F6mgCeIO5N
3t7U8P+zYwhAGQ0pzgdj1mY=P12M
-----END PGP SIGNATURE-----