That's probably an option, though it would break extensions that use `timezone` expecting it to work. But it seems like any change is going to cause that.

I prefer defining _Py_timezone, since at least we can offer something that is portable for all Python 3.5 platforms (that support timezones), unlike timezone/_timezone (MSVC deprecated `timezone` a few versions ago and has just removed it completely, hence the breakage).