icalendar devel - Jan 2006 - Resend: [Fwd: Problems with timezone in generated ical files]

Hi!

I''m resending this since I have got no reply from the list. (Hope
it''s
still alive)

Greetings,
Gitte Wange

-------- Original Message --------
Subject: [iCalendar-devel] Problems with timezone in generated ical files
Date: Thu, 22 Dec 2005 01:35:46 +0100
From: Gitte Wange <gitte at wange.dk>
Reply-To: iCalendar developers &amp; users <icalendar-devel at
rubyforge.org>
To: iCalendar developers &amp; users <icalendar-devel at
rubyforge.org>

Hello again,

I have a major problem with the ical files I generate using the
icalendar module. When importing the ical files into Apple''s ical app,
the events doesn''t have any timezone set.
Looking into an existing ical file, I can see that all the timestamps
looks like:
DTSTART;TZID=Europe/Copenhagen:20050914T190000

In the file I generate using icalendar, they look like:
DTSTART:20050202T010000

What''s missing is the timezone id. I haven''t found any place
in the code
this get''s added. What am I missing?

Greetings,
Gitte Wange
_______________________________________________
icalendar-devel mailing list
icalendar-devel at rubyforge.org
http://rubyforge.org/mailman/listinfo/icalendar-devel

Whoops, I thought I responded before...  This is because the Timezone is
being specified as a parameter of the DTSTART property, and I think I
screwed up the parameter handling.  I''ve been out on holidays, but
I''m
back now and I''ll spend this week working on projects.  I''d
surely
accept patches too :-)

-Jeff

On Sun, 2006-01-08 at 22:53 +0100, Gitte Wange wrote:
> Hi!
> 
> I''m resending this since I have got no reply from the list. (Hope
it''s
> still alive)
> 
> Greetings,
> Gitte Wange
> 
> -------- Original Message --------
> Subject: [iCalendar-devel] Problems with timezone in generated ical files
> Date: Thu, 22 Dec 2005 01:35:46 +0100
> From: Gitte Wange <gitte at wange.dk>
> Reply-To: iCalendar developers &amp; users <icalendar-devel at
rubyforge.org>
> To: iCalendar developers &amp; users <icalendar-devel at
rubyforge.org>
> 
> Hello again,
> 
> I have a major problem with the ical files I generate using the
> icalendar module. When importing the ical files into Apple''s ical
app,
> the events doesn''t have any timezone set.
> Looking into an existing ical file, I can see that all the timestamps
> looks like:
> DTSTART;TZID=Europe/Copenhagen:20050914T190000
> 
> In the file I generate using icalendar, they look like:
> DTSTART:20050202T010000
> 
> What''s missing is the timezone id. I haven''t found any
place in the code
> this get''s added. What am I missing?
> 
> Greetings,
> Gitte Wange
> _______________________________________________
> icalendar-devel mailing list
> icalendar-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/icalendar-devel

Jeff Rose wrote:
> Whoops, I thought I responded before...  This is because the Timezone is
> being specified as a parameter of the DTSTART property, and I think I
> screwed up the parameter handling.  I''ve been out on holidays, but
I''m
> back now and I''ll spend this week working on projects. 
I''d surely
> accept patches too :-)
Hope you had a nice vacation :-)

Well I''d be happy to supply patches, but I''m having some
trouble finding
my way around the code.
Although I have a patch for you for the conversions.rb (String class) 
because I had some problems with encoding and danish characters (I have 
attached it to this mail).
I''m not sure why the String class printed the way it did, but it worked
very badly with unicode characters.

I would love to help out improving this module, but the TZID problem I 
have not yet found a solution for :-(

Greetings,
Gitte Wange
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: conversions.rb.patch
Url:
http://rubyforge.org/pipermail/icalendar-devel/attachments/20060109/bf9bfa4d/conversions.rb.bat

On Mon, 2006-01-09 at 00:20 +0100, Gitte Wange wrote:
> Jeff Rose wrote:
> > Whoops, I thought I responded before...  This is because the Timezone
is
> > being specified as a parameter of the DTSTART property, and I think I
> > screwed up the parameter handling.  I''ve been out on
holidays, but I''m
> > back now and I''ll spend this week working on projects. 
I''d surely
> > accept patches too :-)
> 
> Hope you had a nice vacation :-)
> 
> Well I''d be happy to supply patches, but I''m having some
trouble finding
> my way around the code.
Cool.  I''ve put in your patch.  I don''t remember why I had the
sort of
odd dump there (should have put a comment), but for now we can go with
what you have.  If you could send me a unit test or at least a piece of
code that breaks the old version that would be great.  I''m trying to
write a test each time someone finds a new bug so I make sure it stays
fixed...

As for the parameter stuff, I can give you a better description now that
I''ve looked over it again, and maybe you can help with ideas or a patch
or both...  

Currently the parser is parsing parameters and the generator spits them
back out when printing.  They are stored per property in a hash
(@property_params) in the Component class.  Basically everything is
ready to support parameters in the API except for the API itself that
just sets the hash value.  So if we can figure out how the API should
look then it should be very quick to implement what''s needed.  Using
your DTSTART property as an example, we just need to decide on at least
an initial attempt at a good parameter API.

So currently you do something like:

myevent.start = Date.today

Now we need to add something for the timezone parameter.  This should
probably be generic so that any arbitrary property can work.  How about
this for starters:

myevent.start = Date.today, "TZID", "Europe/Copenhagen"

Where the first item is always the value, the second if it exists is a
parameter, and the rest if they exist are parameter values. Or we could
use a hash:

myevent.start = Date.today, {:param = "TZID", :val
"Europe/Copenhagen"}

I think I like the hash better...  What do you think?  Either way it
would just be a small addition to the generators ical_property and
ical_multi_property so I can maybe even get it done today.

> Although I have a patch for you for the conversions.rb (String class) 
> because I had some problems with encoding and danish characters (I have 
> attached it to this mail).
> I''m not sure why the String class printed the way it did, but it
worked
> very badly with unicode characters.
> 
> I would love to help out improving this module, but the TZID problem I 
> have not yet found a solution for :-(
> 
> Greetings,
> Gitte Wange
If you want to look at it you can look at parser.rb to see how it parses
parameters into the @property_params and component.rb to see it print
those parameters.  Component.ical_property is a method generator that is
used for all the properties that have a single instance, and
Component.ical_multi_property is a generator for properties that have
multiple instances.  If you look at components/event.rb you can see how
they are used.

Ciao,
Jeff

> plain text document attachment (conversions.rb.patch)
> --- conversions.rb.orig	Thu Dec  1 00:46:49 2005
> +++ conversions.rb	Wed Dec 28 23:41:21 2005
> @@ -20,7 +20,7 @@
>  
>  class String
>    def to_ical
> -    "#{self.dump[1...-1]}"
> +    "#{self}"
>    end
>  end
>  
> _______________________________________________
> icalendar-devel mailing list
> icalendar-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/icalendar-devel

>
> So currently you do something like:
>
> myevent.start = Date.today
>
> Now we need to add something for the timezone parameter.  This should
> probably be generic so that any arbitrary property can work.  How  
> about
> this for starters:
>
> myevent.start = Date.today, "TZID", "Europe/Copenhagen"
>
> Where the first item is always the value, the second if it exists is a
> parameter, and the rest if they exist are parameter values. Or we  
> could
> use a hash:
>
> myevent.start = Date.today, {:param = "TZID", :val >
"Europe/Copenhagen"}
>
> I think I like the hash better...  What do you think?  Either way it
> would just be a small addition to the generators ical_property and
> ical_multi_property so I can maybe even get it done today.
Why not just:

myevent.start = Date.today, { :TZID => "Europe/Copenhagen", ... }

That way you could even leave off the braces. Rails uses this idiom a  
lot. It seems like the :param, :val syntax is unnecessary. However, I  
haven''t thought about the special cases. Feel free to correct me if  
I''m missing something. :-)

Brad

On Mon, 2006-01-09 at 08:17 -0600, Brad Ediger wrote:
> >
> > So currently you do something like:
> >
> > myevent.start = Date.today
> >
> > Now we need to add something for the timezone parameter.  This should
> > probably be generic so that any arbitrary property can work.  How  
> > about
> > this for starters:
> >
> > myevent.start = Date.today, "TZID",
"Europe/Copenhagen"
> >
> > Where the first item is always the value, the second if it exists is a
> > parameter, and the rest if they exist are parameter values. Or we  
> > could
> > use a hash:
> >
> > myevent.start = Date.today, {:param = "TZID", :val > >
"Europe/Copenhagen"}
> >
> > I think I like the hash better...  What do you think?  Either way it
> > would just be a small addition to the generators ical_property and
> > ical_multi_property so I can maybe even get it done today.
> 
> Why not just:
> 
> myevent.start = Date.today, { :TZID => "Europe/Copenhagen",
... }
> 
> That way you could even leave off the braces. Rails uses this idiom a  
> lot. It seems like the :param, :val syntax is unnecessary. However, I  
> haven''t thought about the special cases. Feel free to correct me
if
> I''m missing something. :-)
> 
> Brad
Good call, this is even better.  I''ll work on it this afternoon!

-Jeff
> _______________________________________________
> icalendar-devel mailing list
> icalendar-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/icalendar-devel

ok, I''ve added the hash syntax to the setters.  (After 15 minutes of
figuring out how things were setup originally it ended up being a two
minute change...)

How should the getters work though?  Currently it works like this:

  # single instance property
  myevent.start = Date.today
  ...
  start_date = myevent.start
  # start_date is a date object 

  # multi-instance property
  myevent.add_attendee "jsmith at foo.com", {:CN => "John
Smith"}
  myevent.add_attendee "mjones at foo.com", {:CN => "Mary
Jones"}
  ...
  attendees = myevent.attendees
  # attendees = ["jsmith at foo.com", "mjones at foo.com"]

What should it look like for the params?  We could have:

  start_params = myevent.start_params  
  # start_params = {:TZID => "Europe/Copenhagen"}

  attendees_params = myevent.attendees_params
  # attendees_params = [{:CN => "John Smith"}, {:CN =>
"Mary Jones"}]

I don''t know how much I like that though...  Any ideas or suggestions?


-Jeff