From regebro at gmail.com  Fri Jan  2 13:19:27 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 2 Jan 2009 13:19:27 +0100
Subject: [icalendar-dev] Get DTStart with time zone
In-Reply-To: <319e029f0811070019h27086565l1806bd550ab033e9@mail.gmail.com>
References: <f210cc530810171554l27085cb3u5a56929b5f948320@mail.gmail.com>
	<319e029f0811070019h27086565l1806bd550ab033e9@mail.gmail.com>
Message-ID: <319e029f0901020419v57aa6024u83da282a22a6795c@mail.gmail.com>

On Fri, Nov 7, 2008 at 09:19, Lennart Regebro <regebro at gmail.com> wrote:
> On Fri, Oct 17, 2008 at 23:54, Stephen Judd <sgj at brothersjudd.com> wrote:
>> How can I get the DTStart with the correct tz information when the timezone
>> is in the DTStart as a parameter?
>>
>> e.g., DTSTART;TZID=US/Pacific:20081020T160000
>>
>> decoded('DTStart') gives me a datetime with no tzinfo.
>
> I don't remember how this works, I'll have to look into that.

OK, got it now. Complicated stuff.

That DTSTART will return a vDDDTypes with TZINFO and a datetime, but
the datetime will not have timezone set. Currently, you then need to
check if the property has a TZINFO set, and in that case, map that to
a VTIMEZONE from the calendar object. That in turn needs to be
converted or mapped to some sort of tzinfo object, for example the
FixedOffsett objects that comes with iCalendar, and that tzinfo needs
to be set to the date time.

This, IMO, is too complicated, iCalendar should do this itself. The
problem is that you then need to pass ifnormation from the calendar
object to the date time parsing, which requires some changes in the
iCalendar infrastructure.

Therefore, I'd like to check if anybody else, MaxM in particular, has
any better ideas.

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From sgj at brothersjudd.com  Fri Jan  2 14:03:05 2009
From: sgj at brothersjudd.com (Stephen Judd)
Date: Fri, 2 Jan 2009 08:03:05 -0500
Subject: [icalendar-dev] Get DTStart with time zone
In-Reply-To: <319e029f0901020419v57aa6024u83da282a22a6795c@mail.gmail.com>
References: <f210cc530810171554l27085cb3u5a56929b5f948320@mail.gmail.com>
	<319e029f0811070019h27086565l1806bd550ab033e9@mail.gmail.com>
	<319e029f0901020419v57aa6024u83da282a22a6795c@mail.gmail.com>
Message-ID: <f210cc530901020503y454effe8x436df362d97f51b3@mail.gmail.com>

I ended up using a regular expression to check:

curTZString = re.search('(?<=TZID=)[^:]*(?:)', str(e))
if curTZString:
  curTZ = timezone(curTZString.group(0))

Using pytz to handle the conversion of the string to a timezone object.

Thanks, Steve

On Fri, Jan 2, 2009 at 7:19 AM, Lennart Regebro <regebro at gmail.com> wrote:

> On Fri, Nov 7, 2008 at 09:19, Lennart Regebro <regebro at gmail.com> wrote:
> > On Fri, Oct 17, 2008 at 23:54, Stephen Judd <sgj at brothersjudd.com>
> wrote:
> >> How can I get the DTStart with the correct tz information when the
> timezone
> >> is in the DTStart as a parameter?
> >>
> >> e.g., DTSTART;TZID=US/Pacific:20081020T160000
> >>
> >> decoded('DTStart') gives me a datetime with no tzinfo.
> >
> > I don't remember how this works, I'll have to look into that.
>
> OK, got it now. Complicated stuff.
>
> That DTSTART will return a vDDDTypes with TZINFO and a datetime, but
> the datetime will not have timezone set. Currently, you then need to
> check if the property has a TZINFO set, and in that case, map that to
> a VTIMEZONE from the calendar object. That in turn needs to be
> converted or mapped to some sort of tzinfo object, for example the
> FixedOffsett objects that comes with iCalendar, and that tzinfo needs
> to be set to the date time.
>
> This, IMO, is too complicated, iCalendar should do this itself. The
> problem is that you then need to pass ifnormation from the calendar
> object to the date time parsing, which requires some changes in the
> iCalendar infrastructure.
>
> Therefore, I'd like to check if anybody else, MaxM in particular, has
> any better ideas.
>
> --
> Lennart Regebro: Zope and Plone consulting.
> http://www.colliberty.com/
> +33 661 58 14 64
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/icalendar-dev/attachments/20090102/8cd4f95e/attachment-0001.htm 

From regebro at gmail.com  Thu Jan  8 13:59:54 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 8 Jan 2009 13:59:54 +0100
Subject: [icalendar-dev] API design poll for all users
Message-ID: <319e029f0901080459p32dc67e0m2200fa8cddeade46@mail.gmail.com>

For fun I'm looking into porting iCalendar to Python3. One design
choice of iCalendar turns out to be problematic: The  common use of
str(something) to get the iCalendar data. This because of course, in
Python 3 __str__ needs to return the unicode strings of Python 3,
while the data return must be UTF8 encoded binaries.

So, I'm going to deprecate that API, as it doens't work in Python 3.

But then we come to the question of when to use instead. The Calendar
class and Contentlines uses as_string() and from_string() from the
conversion. Those work of course, but in Python 3 it won't be to or
from strings, so that naming doesn't make sense. So I'm gonna
deprecate those too. I decided to use encode/decode instead, where
decode takes the binary UTF8 encoded data and gives you back objects,
and encode does the opposite. Then I remembered that properties
doesn't use as_string/from_string, to ical/from_ical. That's
inconsistent.

 So the question is: Should I switch as_string()/from_string to
ical/from_ical as well? On the other hand I like encode/decode better.
On the other hand, that could be confusing if you expect to get
unicode objects back from decode(), or if you think you can pass
encodings to decode() (You can't RFC2455 only support s UTF8).

So what do people think? I'm currently leaning towards renaming all
methods to_ical/from_ical (I prefer that symmetry to ical/from_ical).
But I seem to change my mind every five minutes, so some feedback
would be nice. :)

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64

From maxm at mxm.dk  Thu Jan  8 14:33:28 2009
From: maxm at mxm.dk (Max M)
Date: Thu, 08 Jan 2009 14:33:28 +0100
Subject: [icalendar-dev] API design poll for all users
In-Reply-To: <319e029f0901080459p32dc67e0m2200fa8cddeade46@mail.gmail.com>
References: <319e029f0901080459p32dc67e0m2200fa8cddeade46@mail.gmail.com>
Message-ID: <496600A8.8090302@mxm.dk>

Lennart Regebro skrev:
> For fun I'm looking into porting iCalendar to Python3. 

Strange idea of fun ;-)


> One design
> choice of iCalendar turns out to be problematic: The  common use of
> str(something) to get the iCalendar data. This because of course, in
> Python 3 __str__ needs to return the unicode strings of Python 3,
> while the data return must be UTF8 encoded binaries.
> 
> So, I'm going to deprecate that API, as it doens't work in Python 3.

Yeah bummer. I need Guidos time machine on that.


>  So the question is: Should I switch as_string()/from_string to
> ical/from_ical as well? On the other hand I like encode/decode better.
> On the other hand, that could be confusing if you expect to get
> unicode objects back from decode(), or if you think you can pass
> encodings to decode() (You can't RFC2455 only support s UTF8).

encode/decode is not in any way obvious or precise. So I dont like those 
at all.

to_ical/from_ical is sort of ok. And if guido changes the string type 
once more we do not need to change the api ;-) The problem with it 
though is that most people would probably be confused when from_ical 
suddenly means from bytes and not from an ical object. It actually reads 
the opposite of what it means.

As far as I understand the 3K encoded string is called bytes. So my 
choice would probably be to just say that directly. to_bytes() 
from_bytes() I think that is as obvious as it can get.



-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

Phone:  +45 66 11 84 94
Mobile: +45 29 93 42 96


From regebro at gmail.com  Thu Jan  8 15:25:38 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 8 Jan 2009 15:25:38 +0100
Subject: [icalendar-dev] API design poll for all users
In-Reply-To: <496600A8.8090302@mxm.dk>
References: <319e029f0901080459p32dc67e0m2200fa8cddeade46@mail.gmail.com>
	<496600A8.8090302@mxm.dk>
Message-ID: <319e029f0901080625i2e7cee78u6edb5b93665a62d7@mail.gmail.com>

On Thu, Jan 8, 2009 at 14:33, Max M <maxm at mxm.dk> wrote:
> As far as I understand the 3K encoded string is called bytes. So my choice
> would probably be to just say that directly. to_bytes() from_bytes() I think
> that is as obvious as it can get.

That's OK for me. Although in 2.x it won't be bytes but strings, and
the API's should be the same, or porting to Python 3 for iCalendar
users will be needlessly painful, so it will be called
to_bytes/from_bytes under Python 2.5 as well. (Although the old
methods will remain, with deprecation warnings).

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64