>>> 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 names
despite 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 if
the 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 as
  Lib/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