On my Ubuntu machine, I get:

$ zdump -v Europe/Moscow | grep 201[0-9]
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
[and nothing else, whereas other locations can show changes up to year 2499]

If I read this information correctly, this says that about 8 months ago, DST was not applied as usual; instead, the definition of MSK changed from UTC+3 to UTC+4.
Of course Python uses the same data, so is right to display tm_idst=0.

OTOH, time.timezone should be -4*3600==-14400, and here I think Python is wrong.  Also, time.daylight should be zero, whereas:

$ TZ=Europe/Moscow ./python
Python 3.3.0a0 (default:53cc2668d54f, Nov 23 2011, 22:19:40) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname, time.timezone, time.daylight
(('MSK', 'MSK'), -10800, 1)

The error comes from the way Python computes timezone and daylight: it queries the tm_gmtoff of two timestamps, one close to the first of January, the other close to the first of July.  But last January the previous definition of the timezone was still in force...  and indeed, when I changed the code to use *next* January instead, I have the expected values.

Is there an algorithm that gives the correct answer?  Taking the 1st of January closest to the current date would not work either.  Or is there another way (in portable C) to approach timezones?