>>> import os  >>> import time  >>> os.environ['TZ'] = 'Europe/Moscow'  >>> time.tzset()  >>> time.strptime('2010-06-01 MSK', '%Y-%m-%d %Z')  time.struct_time(tm_year=2010, tm_mon=6, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=1, tm_yday=152, tm_isdst=0)  >>> time.strptime('2010-06-01 MSD', '%Y-%m-%d %Z')  Traceback (most recent call last):    File "<stdin>", line 1, in <module>    File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time      return _strptime(data_string, format)[0]    File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime      (data_string, format))  ValueError: time data '2010-06-01 MSD' does not match format '%Y-%m-%d %Z'datetime.strptime() and Python 3 behavior is exactly the same. The correct name is MSD:  >>> from datetime import datetime, timezone  >>> dt = datetime(2010, 5, 31, 21, tzinfo=timezone.utc).astimezone()  >>> dt.strftime('%Y-%m-%d %Z')  '2010-06-01 MSD'strptime() uses the current (wrong for the past date) time.tzname namesdespite the correct name being known to the system (as the example above demonstrates).In general, it is impossible to validate a time zone abbreviation even ifthe time zone database is available:- tzname may be ambiguous -- multiple zoneinfo matches (around one third  of tznames the tz database correspond to multiple UTC offsets (at the  same or different times) -- it is not unusual) i.e., any scheme that   assumes that tzname is enough to get UTC offset such asLib/email/_parsedate.py is wrong.- and even if zoneinfo is known, it may be misleading e.g.,   e.g., HAST (Hawaii-Aleutian Standard Time) might be rejected  because Pacific/Honolulu zoneinfo uses HST. HAST corresponds to   America/Adak (US/Aleutian) in tzdata (UTC offset may be the same).  It might be too rare to care.Related:issue22377

Correction:The correct offset is +0400:  >>> dt = datetime(2010, 5, 31, 20, tzinfo=timezone.utc).astimezone()And _timezones dict is defined inLib/email/_parseaddr.py

There is no daylight savings time in Moscow and python detects this correctly:$ TZ=Europe/Moscow python3>>> import time>>> time.daylight0Note that historically, there was DST, but time module cannot handle historical TZ changes.(Russian government compensates the relative sanity of not moving the clocks twice a year by changing the UTC offset and TZ boundaries every 5 years or so.:-)

I don't think there is anything we can do here.  Without a TZ database, Python has to rely on time.tzname which in case of TZ=Europe/Moscow returns>>> time.tzname('MSK', 'MSK')Hardcoding a timezones dictionary as done in email module may work for a handful of American timezones, but will not work for TZ's like Europe/Moscow.$ zdump -v  Europe/Moscow| tailEurope/Moscow  Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD isdst=1Europe/Moscow  Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK isdst=0Europe/Moscow  Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0Europe/Moscow  Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1Europe/Moscow  Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1Europe/Moscow  Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0Europe/Moscow  Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0Europe/Moscow  Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0Europe/Moscow  Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 MSK isdst=0Europe/Moscow  Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 MSK isdst=0(And it looks like the planned for 2014-10-26 switch back to winter time is not in my laptop's database yet.)

On the second thought, we can probably make the same guesswork as in PyInit_timezone (seeModules/timemodule.c) in time.strptime, but not for the current time, but for the time parsed.

My patch forissue22377 also fixes this bug.With the patch applied. Both MSK and MSD are accepted if the new timezones parameter is false (default for Python 3.5, will be changed to True in Python 3.6If timezones is True then MSD return a correct aware datetime object,MSK is rejected.

MSD variant works on my machine because C library usesthe historical timezone database there. I'm not sure whether itworks on old Windows versions.