Hide Forgot
libical seems to give incorrect tz rules for Moscow. Using the following test program: #include <libical/icaltimezone.h> #include <stdio.h> int main(int argc, char **argv) { icaltimezone *tz = icaltimezone_get_builtin_timezone (argv[1]); icaltimezone_dump_changes (tz, 2012, stdout); } [dwmw2@shinybook ~]$ ./tztest Europe/Moscow | tail -5 Europe/Moscow 30 Oct 2010 23:00:00 +0300 Europe/Moscow 26 Mar 2011 23:00:00 +0400 Europe/Moscow 29 Oct 2011 23:00:00 +0300 Europe/Moscow 24 Mar 2012 23:00:00 +0400 Europe/Moscow 27 Oct 2012 23:00:00 +0300 This is wrong; Moscow is remaining on GMT+4 from March 2011 onwards, for the foreseeable future. libical seems to have heuristics to infer the recurrence rules for DST changes, but they are not working. It scares me that we even *need* heuristics for that; doesn't the tzdata file give you all the information you need? zdump seems to get this right: [dwmw2@shinybook fedora]$ zdump -c2010,2012 -v Europe/Moscow Europe/Moscow -9223372036854775808 = NULL Europe/Moscow -9223372036854689408 = NULL Europe/Moscow Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0 gmtoff=10800 Europe/Moscow Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1 gmtoff=14400 Europe/Moscow Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1 gmtoff=14400 Europe/Moscow Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0 gmtoff=10800 Europe/Moscow Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0 gmtoff=10800 Europe/Moscow Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0 gmtoff=14400 Europe/Moscow 9223372036854689407 = NULL Europe/Moscow 9223372036854775807 = NULL
https://sourceforge.net/tracker/?func=detail&aid=3432224&group_id=16077&atid=116077
(In reply to comment #0) > It scares me that we even *need* heuristics for that; > doesn't the tzdata file give you all the information you need? As noted in the sf.net bug: Yes, it does. The 'version 2' tzdata file format (since 2005) has a POSIX $TZ-style string which defines the rules for instances after the last defined transition in the file. It looks something like this: PST8PDT,M3.2.0,M11.1.0 or this: GMT0BST,M3.5.0/1,M10.5.0 Or, in the case of Russia since the tzdata update, it's empty. See http://www.gnu.org/s/hello/manual/libc/TZ-Variable.html for a reference on how to decode the string.
I'm pretty sure here is noone who would duplicate work with upstream, thus, the most, their change would be included in an update, in case it'll be easily identified. Otherwise we would wait for a new release of libical. Either way, I'm closing this as upstream.