[libical] wrong timezone info using libical

Suman Manjunath manjunath.suman at gmail.com
Fri Feb 13 02:40:39 PST 2009


Hello,

libical svn trunk provides wrong timezone information for two
timezones in Australia (Eucla/Perth)

Steps to reproduce:
1) checkout libical svn trunk, autogen, configure, make
2) under src/test, run 'make timezones' then run the generated test
program 'timezones'

Present output:
Australia/Perth: day 000: first failed: libc 2009-02-13 12:00:00 dst 1
!= libical 2009-02-13 11:00:00 dst 0
Australia/Perth: day 044: okay again: libc 2009-03-29 11:00:00 dst 0
Australia/Eucla: day 000: first failed: libc 2009-02-13 12:00:00 dst 1
!= libical 2009-02-13 11:00:00 dst 0
Australia/Eucla: day 044: okay again: libc 2009-03-29 11:00:00 dst 0
 *** Summary: 401 zones tested, 88 days failed, 146277 okay => 0% failed ***

Output after applying attached patch:
Australia/Perth: day 254: first failed: libc 2009-10-25 11:00:00 dst 0
!= libical 2009-10-25 12:00:00 dst 1
Australia/Eucla: day 254: first failed: libc 2009-10-25 11:00:00 dst 0
!= libical 2009-10-25 12:00:00 dst 1
 *** Summary: 401 zones tested, 222 days failed, 146143 okay => 0% failed ***

A little bit of explanation:
libical operates on RRULES. The STANDARD component has a rule, the
DAYLIGHT component has a rule. All the dates that fall within the
limits of these rules fall into one or the other categories.
GLibc does not operate that way. Given a point in time, it tries to
calculate if any daylight savings rule applies to that given instant.
The time offset is then calculated accordingly.

This is precisely the reason why the test program fails even after
applying the patch. At present, there is no rule for
Australia(Perth/Eucla) to govern what happens on the last Sunday of
October in 2009. i.e. there is no apparent switch to DST. 9 out of 10
times, it is just because the rule may not be officially accepted yet
and not because the rule was intended to removed altogether.

With the patch, libical tries to extrapolate (and yes, predict) the
last applicable transition to the relevant date in the current year.

Why should I apply the patch if it is not the complete fix anyway?
As of now, libical provides wrong timezone data. i.e. it is indeed DST
in those two locations right now but libical says otherwise. With the
patch, libical tries to provide the correct timezone offsets for all
"known and confirmed" data and tries to predict for the "unconfirmed
and most-likely-to-be-true" data.

Is there a better way to fix this issue? Or is it okay to take this
incomplete fix upstream?

Regards,
-Suman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: use-last-transition.diff
Type: text/x-patch
Size: 350 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-interest/attachments/20090213/a747ed98/attachment.bin>


More information about the libical-interest mailing list