[Kde-pim] [Libical] libical 0.27 is now available

[Jason 'vanRijn' Kasper]

On Monday 26 March 2007 07:14:02 David Jarvie wrote:
> On Mon, March 26, 2007 12:00 pm, Reinhold Kainhofer wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Am Montag, 26. März 2007 schrieb David Jarvie:
> >> On Sat, March 24, 2007 2:56 pm, Allen Winter wrote:
> >> > On Wednesday 21 March 2007 6:06:51 pm Reinhold Kainhofer wrote:
> >> >> Am Mittwoch, 28. Februar 2007 schrieb IGnatius T Foobar:
> >> >> >  For anyone interested...
> >> >> >
> >> >> >    http://easyinstall.citadel.org/libical-0.27.tar.gz
> >> >> >
> >> >> >  tzdata is updated to 2007c (includes the changes for Daylight
> >>
> >> Savings
> >>
> >> >> > Time in the US) as well as a couple of minor bugfixes.
> >> >>
> >> >> I took a look at the files now, and it seems that the DST changes in
> >>
> >> the
> >>
> >> >> US
> >> >> were implemented wrong. The files contain e.g.
> >> >
> >> > We need to have a fix right away.
> >> > What to do?
> >> > http://bugs.kde.org/show_bug.cgi?id=143409
> >>
> >> This has jogged my memory about a bug I discovered some time ago in the
> >> libical time zone definitions. They were updated about a year ago by
> >> Tepper Hasso. Many of the definitions are actually completely wrong in
> >> the
> >> same manner as the new USA definitions. For example, Europe/London also
> >> has only a single blanket definition starting in 1970, whereas the
> >> previous (correct) version has many different definitions for different
> >> years starting in the 19th century. The current version is wrong even
> >> for
> >> some years post-1970. Tepper's commit needs to be reverted, and then the
> >> new USA stuff needs to be added.
> >
> > Actually, the Olsen database is a comprehensive database of all
> > historical DST
> > occurrences, too. So basically all that we need is a proper converter
> > from the ODB to iCalendar... There are such converters, but I don't know
> > how good
> > they work.
> > See http://www.twinsun.com/tz/tz-link.htm
> >
> > Only using the system-wide zoneinfo files, it will never be possible to
> > properly generate historical times.
> >
> > I don't have time currently to look into that issue with really broken TZ
> > definitions... I suppose unless we find an easy cleaner solution, it is
> > best
> > now to use the wrong fix and in the future generate proper VTIMEZONE
> > snipplets with all historical data directly from the Olsen DB.
>
> But before updating the USA data, Hasso's commit should be reverted. The
> current libical definitions in SVN (3.5 and trunk) are completely wrong
> for past years.

But the largest impact of the incorrect definitions is on current and future 
events.  For example, I have been missing meetings for the last 15 days 
because korg has shown my events an hour off (since March 11).  That _must_ 
get fixed (and is the approach that Redhat has taken with 
evolution-data-server).  If the result of that is that some past events are 
shown an hour off and only during the period between old and new timezone 
changes, I don't care at all, and I would bet money that 95% of our users 
won't even notice.  But I think that we absolutely must fix the current and 
future events that are off immediately and only after that try to get a 
complete and technically correct solution which addresses the past events.

Passionately pleadingly yours,

Me.  =;)

-- 
 -[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
 -[ KDE PIM Developer         //  http://www.kde.org  ]-
 -[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/