From: Patrick O. <pat...@gm...> - 2011-09-06 15:51:22
|
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 -- Pat...@gm... http://www.estamos.de/ |