Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-16 Thread chenthill palanisamy
On Tue, 2008-04-15 at 18:07 +0200, Patrick Ohly wrote:
 On Tue, 2008-04-15 at 13:59 +0530, chenthill wrote: 
  To preserve the timezone history, the best way would be to store the old
  rules in VTIMEZONES which should be done in libical.
 
 If I understand you correctly, you are suggesting to merge a VTIMEZONE
 with TZID=FOO that comes with a new meeting invitation with a previously
 stored VTIMEZONE with the same TZID, so that the merged VTIMEZONE has
 the rules from both the original VTIMEZONE.
 
 The problem is that incoming VTIMEZONE definitions from Exchange do not
 contain information to which year the rules apply. In the examples that
 I quoted, both use DTSTART:16010101T02 and thus are mutually
 exclusive.
Nope I don't mean merging here. The VTIMEZONE from libical currently do
not provide the history of timezone changes (older + current rrules) for
the system timezones. Libical should be modified so that the VTIMEZONE's
generated stores the timezone history. The Tzfile would have the history
stored on the system, libical just does not store it in VTIMEZONE.


Say if a meeting is received from exchange server with some Tzid for
America/New_York. As we discussed below, this needs to be mapped to
system timezone and libical should provide the VTIMEZONE which has the
timezone history.  This way, we need not use the VTIMEZONE sent by
exchange and still display the older/current events properly.

 
  I do not recommend having another set of tzid's with
  versions in it for maintaining the old rules. This would trigger the
  comparison of rules between different versions of timezones.
 
 I don't get this part. Can you elaborate what you mean? Are you saying
 that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts
 with an existing VTIMEZONE should be avoided?
yes, if  libical is modified to return VTIMEZONE with the history and
once mapping between foreign timezones to system timezones is done at
the backend, this is would not be required. All the older events would
be properly displayed.

 
   Once the
  outlook timezones are mapped with libical ones, the libical timezones
  which would have the old rules can be used.
 
 Mapping foreign TZIDs to system timezones always should be attempted
 first. Storing a VTIMEZONE under a different name is only the fallback.
 
   [VTIMEZONE and VEVENT are added separately]
I don't think it works like that. iirc the whole VCALENDAR (used as
top-level component in itip-formatter) which has events and timezone
gets passed to the backend, the backend adds the timezone and events to
the cache, notifies the UI.
   
   After looking at the Evolution source code I already came to the same
   conclusion. However, clients like SyncEvolution do add VTIMEZONE and
   VEVENT separately. That is necessary because the UID of each new VEVENT
   is required immediately, which is not possible (or at least very
   awkward) via ecal_receive_objects().
  I hope SyncEvolution is the only backend which does it in this way.
 
 SyncEvolution is not a backend. It is a client program using the
 synchronous libecal API.
Ah ok. I misunderstood that it has a corresponding external backend as
well.

 
 I believe OpenSync works the same way, although I haven't looked at it
 during the last two years.
 
   I am
  not sure if we would need a libecal API for this. Is it not possible to
  handle it inside e_cal_backend_add_timezone?
 
 No, because the call cannot return the information to which TZID the
 timezone was mapped. Modifying the icaltimezone *zone would be an API
 change.
The tzid need not be changed for the VEVENT. The following would work
fine even if VTIMEZONE and VEVENT are handled separately,

e_cal_backend_add_timezone - Add the timezone to backend's cache if the
timezone cannot be matched with the system timezone else do not add.

e_cal_backend_get_timezone - use the mapping and provide proper system
timezone or if its unable to map, it needs to get the timezone from the
cache.

The clients can now use the corresponding libecal API's to get the right
timezone. So, I feel this can be done commonly to all backends at EDS.

 
  Yeah you can get the code after two weeks, not a problem. Please file a
  bug on this since the old bug is about, outdated evolution timezones
  which is obsolete now as we pickup the timezones from the system. The
  bug also has a too many comments already. Probably we can also schedule
  a meeting on irc and have a discussion on this. Please let me know the
  time which would be suitable for you.
 
 I'll create a new bug report. Should we move the discussion away from
 this list?

I think if we discuss this on IRC, we can conclude on the design
faster. ´╗┐It would be better to do the patch reviews in bugzilla.

 
 Usually we could meet on IRC during the evening CEST, but there's not
 much time this week.
I may not be available over next week. Let me know a suitable time
during this week or after April 28th.

- Chenthill.

Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-16 Thread Patrick Ohly
On Wed, 2008-04-16 at 13:59 +0530, chenthill palanisamy wrote:
 The VTIMEZONE from libical currently do
 not provide the history of timezone changes (older + current rrules) for
 the system timezones. Libical should be modified so that the VTIMEZONE's
 generated stores the timezone history. The Tzfile would have the history
 stored on the system, libical just does not store it in VTIMEZONE.

Wow, in that case the situation is much worse than I thought. My
impression was that the patch to use system timezone definitions would
solve the problem of using out-dated, incomplete timezone definitions
shipped with Evolution. The truth is that it only eases the maintenance
pain regarding out-dated definitions, but doesn't address the timezones
change over time problem at all, right?

If this was a known limitation, why was it not already filed as bug a
long time ago? Evolution users running into timezone problems were
instead told to update to the latest Evolution release and update their
system timezone definitions, which in many cases didn't help at all.

 Say if a meeting is received from exchange server with some Tzid for
 America/New_York. As we discussed below, this needs to be mapped to
 system timezone and libical should provide the VTIMEZONE which has the
 timezone history.  This way, we need not use the VTIMEZONE sent by
 exchange and still display the older/current events properly.

I agree that libical absolutely must use the complete timezone history
stored on the system. This is independent from mapping foreign TZIDs
to native ones; both is necessary, but can be implemented separately. Do
you have an estimate how much work improvements for libical would be?
Where are the places which have to be changed? How can we distinguish
between extracting a VTIMEZONE which is to be sent to some other program
and extracting a VTIMEZONE for internal use?

Finally, one organizational question: should a patch be prepared against
the libical in the GNOME or the SF repository? According to this post,
the SF repository is trying to consolidate the various versions floating
around:
http://sourceforge.net/forum/forum.php?thread_id=1912252forum_id=51011

How does the Evolution team stand with regards to that effort?

   I do not recommend having another set of tzid's with
   versions in it for maintaining the old rules. This would trigger the
   comparison of rules between different versions of timezones.
  
  I don't get this part. Can you elaborate what you mean? Are you saying
  that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts
  with an existing VTIMEZONE should be avoided?
 yes, if  libical is modified to return VTIMEZONE with the history and
 once mapping between foreign timezones to system timezones is done at
 the backend, this is would not be required. All the older events would
 be properly displayed.

You assume that the mapping works in all cases. I don't think this is
realistic. There will always be a program FOO somewhere, somewhen using
a TZID=BAR which is unknown to Evolution and thus cannot be mapped. Even
getting this right just for Outlook alone will be challenging and
require permanent maintenance.

   I hope SyncEvolution is the only backend which does it in this way.
  
  SyncEvolution is not a backend. It is a client program using the
  synchronous libecal API.
 Ah ok. I misunderstood that it has a corresponding external backend as
 well.

Have a look at http://www.estamos.de/projects/SyncML/index.html -
calling a SyncML server that VEVENTs are exchanged with external
backend kind of fits, but not quite.

I am
   not sure if we would need a libecal API for this. Is it not possible to
   handle it inside e_cal_backend_add_timezone?
  
  No, because the call cannot return the information to which TZID the
  timezone was mapped. Modifying the icaltimezone *zone would be an API
  change.
 The tzid need not be changed for the VEVENT. The following would work
 fine even if VTIMEZONE and VEVENT are handled separately,
 
 e_cal_backend_add_timezone - Add the timezone to backend's cache if the
 timezone cannot be matched with the system timezone else do not add.
 
 e_cal_backend_get_timezone - use the mapping and provide proper system
 timezone or if its unable to map, it needs to get the timezone from the
 cache.
 
 The clients can now use the corresponding libecal API's to get the right
 timezone. So, I feel this can be done commonly to all backends at EDS.

This fails to handle VTIMEZONE definition collisions in those cases
where no mapping to system timezones is found. In that case the
VTIMEZONE needs to be stored with a different TZID and the VEVENT needs
to be patched.

-- 
Bye, Patrick Ohly
--  
[EMAIL PROTECTED]
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-16 Thread Suman Manjunath
On Wed, Apr 16, 2008 at 10:00 PM, Patrick Ohly [EMAIL PROTECTED] wrote:
 On Wed, 2008-04-16 at 13:59 +0530, chenthill palanisamy wrote:
I don't get this part. Can you elaborate what you mean? Are you saying
that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts
with an existing VTIMEZONE should be avoided?
   yes, if  libical is modified to return VTIMEZONE with the history and
   once mapping between foreign timezones to system timezones is done at
   the backend, this is would not be required. All the older events would
   be properly displayed.

  You assume that the mapping works in all cases. I don't think this is
  realistic. There will always be a program FOO somewhere, somewhen using
  a TZID=BAR which is unknown to Evolution and thus cannot be mapped. Even
  getting this right just for Outlook alone will be challenging and
  require permanent maintenance.

Very true.. it was/is a serious PITA while I was figuring out the
details for the MAPI provider.
On the brighter side, Exchange/Outlook 2007 has got this sorted out to
an extent. They now store the historical rules in the timezone blob.
See [1].
(The MAPI provider does not yet makes use of these rules, it only
identifies the timezone - maps it to one of the system timezones -
then uses the system timezone information to generate the start-end
times of the event.. its a todo on my list to make use of the stored
information :-) )

And, like you have mentioned, the mapping needs constant maintenance
despite publications like [2] or [3] :-(

-Suman

[1] 
http://blogs.msdn.com/stephen_griffin/archive/2006/12/06/outlook-2007-timezone-structures.aspx
[2] http://msdn2.microsoft.com/en-us/library/ms912053.aspx
[3] 
http://technet2.microsoft.com/WindowsVista/en/library/31f49a21-cfed-4b63-b420-58a9eabbb04e1033.mspx?mfr=true
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers