[Freeassociation-devel] TODOs before 0.47

Tue Sep 6 08:51:06 PDT 2011

On Mi, 2011-08-24 at 11:33 +0200, Patrick Ohly wrote:
> On Di, 2011-08-23 at 14:56 -0400, Allen Winter wrote:
> > TODO
> > ---------
> > * some regression tests are failing even though the percentage of success looks good
> >   look closely at the output (grep on regression.c)
> 
> The system time zone test program fails for some zones. At least at some
> point in the past it worked 100% (according to
> https://bugzilla.gnome.org/show_bug.cgi?id=548268#c17). I'll have a look
> at these failures.

Interesting. In the two cases where it fails on my Debian Stable system
it seems to be libc which is wrong. Here's extended output (patch
attached):

Pacific/Fiji: day 295: first failed: 2011-10-23 00:00:00 UTC = libc 2011-10-23 12:00:00 dst 0 != libical 2011-10-23 13:00:00 dst 1
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Pacific/Fiji
X-LIC-LOCATION:Pacific/Fiji
BEGIN:STANDARD
TZNAME:FJT
DTSTART:19700306T030000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=3
TZOFFSETFROM:+1300
TZOFFSETTO:+1200
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:FJST
DTSTART:19701023T020000
RRULE:FREQ=YEARLY;BYDAY=-2SU;BYMONTH=10
TZOFFSETFROM:+1200
TZOFFSETTO:+1300
END:DAYLIGHT
END:VTIMEZONE

According to http://www.timeanddate.com/worldclock/clockchange.html?n=82
FJST is active on 2011-10-23 after 2:00 local time. It'll start on that
date, which is the second last Sunday of October, as specified in the
FJST RRULE.

The test uses a time which is intentionally midday local time because I
didn't want to be overly ambitious with the test and also check for
correct handling of the exact switch. So in this case, the offset
against UTC is +13 hours and dst is active, which is the result given by
libical.

The other case is:

Pacific/Apia: day 267: first failed: 2011-09-25 23:00:00 UTC = libc 2011-09-25 12:00:00 dst 0 != libical 2011-09-25 13:00:00 dst 1
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Pacific/Apia
X-LIC-LOCATION:Pacific/Apia
BEGIN:STANDARD
TZNAME:WST
DTSTART:19700402T040000
RRULE:FREQ=YEARLY;BYDAY=1SA;BYMONTH=4
TZOFFSETFROM:-1000
TZOFFSETTO:-1100
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:WSDT
DTSTART:19700925T000000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=9
TZOFFSETFROM:-1100
TZOFFSETTO:-1000
END:DAYLIGHT
END:VTIMEZONE

Here http://www.timeanddate.com/worldclock/clockchange.html?n=282
doesn't agree with the day on which dst begins. The RRULE above says
last Sunday, timeanddate says Saturday. Again libc doesn't have dst
active.

But perhaps libical *and* timeanddate are wrong? Another site says that
both time zones do not have and dst rules:
http://www.travelmath.com/time-zone/Pacific/Fiji
http://www.travelmath.com/time-zone/Pacific/Apia
http://www.timezoneconverter.com/cgi-bin/zoneinfo.tzc?s=default&tz=Pacific/Fiji

My theory is that these locations had DST in the past, but won't in the
future. The libical conversion code might lack support for that kind of
situation.

If true, there will be fun in Russia this year...

Indeed, on a Debian unstable with more recent zone information
(shouldn't Debian stable get that, too?) I see the same failures also
for Russian locations:
Pacific/Fiji: day 295: first failed: libc 2011-10-23 12:00:00 dst 0 != libical 2011-10-23 13:00:00 dst 1
Atlantic/Stanley: day 106: first failed: libc 2011-04-17 12:00:00 dst 1 != libical 2011-04-17 11:00:00 dst 0
Atlantic/Stanley: day 246: okay again: libc 2011-09-04 12:00:00 dst 1
Europe/Kaliningrad: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Europe/Moscow: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Europe/Volgograd: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Europe/Samara: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Yekaterinburg: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Omsk: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Novosibirsk: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Novokuznetsk: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Krasnoyarsk: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Irkutsk: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Yakutsk: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Vladivostok: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Sakhalin: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Magadan: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Kamchatka: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Asia/Anadyr: day 302: first failed: libc 2011-10-30 13:00:00 dst 0 != libical 2011-10-30 12:00:00 dst 1
Pacific/Apia: day 267: first failed: libc 2011-09-25 12:00:00 dst 0 != libical 2011-09-25 13:00:00 dst 1

The VTIMEZONE for Moscow is definitely wrong:
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Moscow
X-LIC-LOCATION:Europe/Moscow
BEGIN:STANDARD
TZNAME:MSK
DTSTART:19700327T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0300
TZOFFSETTO:+0400
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:MSK
DTSTART:19701030T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0400
TZOFFSETTO:+0300
END:DAYLIGHT
END:VTIMEZONE

DAYLIGHT started Sunday, 27 March 2011, 02:00, and will not end anymore
because Russia wisely decided that this switching back and forth is
foolish.

=> https://sourceforge.net/tracker/?func=detail&aid=3405041&group_id=16077&atid=116077

> > * Bugs-3287603: Memory leak in icaltimezone_set_component
> 
> I also see some leaks in my nightly testing. Will have a look.

That turned out to be a leak in the layer above libical. Now all is
fine.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly at gmx.de
http://www.estamos.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-timezone-test-print-VTIMEZONE-and-UTC-time.patch
Type: text/x-patch
Size: 2538 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20110906/b9f4dcab/attachment.bin>