I have made my mind on subclassing timezone issue.  I believe subclassing should not be allowed and here is the reason:

The new datetime.timezone class is a very specific implementation of tzinfo interface.  It guarantees that utcoffset(dt) and friends return the same value for all times.  Applications should be able to rely on this and a simple isinstance(tz, timezone) should be enough to deduce that tz is a fixed offset tzinfo instance.  (Of course careful applications can check type(tz) == timezone instead, but making isinstance(tz, timezone) subtly wrong is not a good idea.)

There is also very little to be gained from subclassing timezone.  It defines only 4 methods and each is entirely trivial.  Any non-trivial tzinfo implementation will need to override all 4 of them anyways.  It is much safer to derive from tzinfo directly and possible reuse timezone through containment (for example to format offsets in a standard way.)

The only immediate application of subclassing is to add dst() method returning a fixed offset rather than None.  This is trivial to implement through containment and if such class becomes popular, I would prefer to add this functionality to timezone class itself.