--===============2095560037==
Content-Type: multipart/signed;
  boundary="nextPart23661974.6fYTeYCWQU";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart23661974.6fYTeYCWQU
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Donnerstag, 24. M=C3=A4rz 2005 21:36 schrieb Allen Winter:
> I finished making all the changes necessary to make kdepim compile with t=
he
> new Calendar constructor that requires a timezoneId (by default I used
> UTC).=20

Good!

> Remember that the only purpose for the timezoneId AFAIK is to determine
> which timezone you want to view Incidences in.=20

Nope, the time in memory are in local time (e.g. if you add a new event), s=
o=20
the tz needs to be used to determine how much you need to shift the times t=
o=20
UTC.=20
But I guess this is just a different view of things. Currently, it's really=
=20
just a property of the view. As mentioned below, recurring events really=20
depend on the time zone they are in:
E.g. an event recurring every monday at 1:00 CEST (UTC+2:00) does not recur=
=20
every monday when viewed in e.g. Eastern time (where the event recurs at=20
19:00 on Sunday). So, recurrence rules heavily depend on the timezone, too!


> Incidence storage should=20
> always be UTC or no timezone (i.e. floating)

With libical 0.24 we can finally also save times with a specific tz attache=
d:

DTSTART;TZID=3D"HelsinkiTime":20030818T100000
DTEND;TZID=3D"HelsinkiTime":20030818T113000

The exact specification of the daylight-saving shift is then given in a=20
separate VTIMEZONE object in the .ics file:

BEGIN:VTIMEZONE
TZID:"HelsinkiTime"
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:EEST
DTSTART:19700329T030000
RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:EET
DTSTART:19701025T040000
RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10
END:STANDARD
END:VTIMEZONE

Currently, libkcal can only read these ones, but cannot write them out, whi=
ch=20
is sub-optimal and the cause of bugs like=20
(http://bugs.kde.org/show_bug.cgi?id=3D76158). Sooner or later, libkcal nee=
ds=20
support for this, but right now we should at least keep in mind that in the=
=20
future the correct tzid will be more important (and then it will not be tak=
en=20
from the entries in /usr/share/zoneinfo, but from .ics snipplets in libical=
's=20
data dir).

> We really need to get this right once and for all.

Definitly.

Cheers,
Reinhold


=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

--nextPart23661974.6fYTeYCWQU
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCQyuPTqjEwhXvPN0RApeuAKCsVB2BJfLA3KTfNTGrUP9MtDIlSwCfTtLZ
bgOIzlgvJZB9N2UamGRfTKY=
=+uMI
-----END PGP SIGNATURE-----

--nextPart23661974.6fYTeYCWQU--

--===============2095560037==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
--===============2095560037==--