Like any other library in other programming languages the Python Standard Library is continuously evolving. Lot of communication and consensus happen for every change or no change that occurs on a specific version. The library clearly has its design principles and it moves and stays accordingly.
The module datetime is no exception. Time points in time space can be created using DateTime and Time classes. A time duration can be created using the timedelta objects. When a point in time is created using datetime or time it can denote a general time. For example, 10 AM on 11th June 2021. Every developer is free to interpret this datetime as it deems fit. A developer can also fix it to a specific timezone. For example 10 AM on 11th June 2021 at Cupertino, California. The first one is a time zone naive object and the second one is the time zone aware object.
On a datetime or time, a developer can mark whether the same time has happened twice. If it has happenned whether this time denotes the first one or the later one is defined through the fold attribute.
The two classes time and datetime for them to be aware of time zones expect their time zone information to be adhering to an interface. The interface is tzinfo. tzinfo is an abstract class. Instances of time and dateTime can be created with the implementations of tzinfo passed on to them. The standard library provides one such implementation called timezone. One can call it a record or equivalent of a C struct having just two pieces of information: an UTC offset and a name. It has very few methods though. The TimeZone class does not do detailed validations. For example it does validate that the UTC offset can not exceed 24 hours in either direction.
Otherwise if a developer creates a timezone instance with +1 hour time delta and calls it UTCPLUSONE through the attribute name its just fine. The class timezone is perfect for creating such instances. Also the timezone class is not DST aware.