[Freeassociation-devel] [libical] wrong timezone info using libical
Suman Manjunath
manjunath.suman at gmail.com
Sun Feb 15 23:54:33 PST 2009
On Fri, Feb 13, 2009 at 21:00, IGnatius T Foobar
<room_freeassociation-devel at uncensored.citadel.org> wrote:
> >Is there a better way to fix this issue? Or is it okay to take this
> >incomplete fix upstream?
>
> If it's good enough for Evolution, it's good enough for upstream.
>
> My only question is, will this break the next time we update the built-in
> tzdata? Or will it continue to be safe?
It should have no effect when the built-in tzdata is updated.
(My understanding is that the --with-builtintz option is only used on
systems which doesn't already have some form tzdata already installed
.... for example: if the option is used on a opensuse 11.1 linux
machine which has glibc + timezone installed, unless the system starts
to use the libical-installed tzdata, the 'timezones' regression test
program will throw _lots_ of errors as the bundled tzdata appears to
be much older than the one installed on my machine (2008h))
The attached patch has a couple of changes:
a) a couple of DST shifts over the weekend uncovered a couple of other
bugs (America/Sao_Paulo, America/Cuiaba and another location). Reason:
libical currently provides DAYLIGHT and STANDARD components that are
applicable for exactly one year, beginning the instant the timezone
was requested. This also extends to the test program which tests the
correctness of the information provided for one year, beginning the
instant the test program began.
This behavior provides inconsistent results. For example, the RRULE
generated for the DAYLIGHT component (for America/Sao_Paulo) in
February 2008 is different from that generated in February 2009 ==>
Using the RRULE for 2009 is incorrect while still in 2008. So, we need
to use the transitions in this year alone to generate the RRULES for
the DAYLIGHT and STANDARD components.
b) It re-writes the find_transidx function to make it more
reader-friendly (the logic remains the same though)
-Suman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aust-libical-fix.diff
Type: text/x-patch
Size: 4784 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20090216/18288f38/attachment.bin>
More information about the libical-devel
mailing list