Let's start with the patched code, in libkcal/calendar.cpp:63:

extern "C" { void set_tz(const char *tzid); } ;

void Calendar::init()
{
  set_tz(mTimeZoneId.latin1());

  mObserver =3D 0;

On FreeBSD systems, the environment variable TZ is normally unset, since=20
/etc/localtime contains all the relevant information and you don't muck w=
ith=20
it. As long as TZ is unset, the system time functions use /etc/localtime =
and=20
it works.=20

However, you also can't naively putenv("TZ") to unset values. Our libc re=
turns=20
an error, and the environment variable is left set to what it was. This m=
eans=20
that because TZ is normally unset at startup, and libical keeps mucking w=
ith=20
the value of TZ every time a time property is accessed, the very _first_ =
time=20
such a thing happens, the timezone gets set to UTC (because libical tries=
 to=20
do computations in UTC) and stays that way. That's why QTime() is off in=20
KOrganizer, and hence the MB line.

To test this, do TZ=3DMST korganizer and watch things work. Or set the ti=
mezone=20
explicitly in Calendar::init(), as above. Or fix libical, that would be a=
=20
possibility as well.

What I don't know is how setting the TZ will affect the way the calendar =
is=20
saved. I seem to remember we used to have dreadful problems with timezone=
s=20
under Linux as well.

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