Consider introducing a separate RegionTimeZone class

[dkhalanskyjb]

Right now, we have an all-encompassing class TimeZone and its subclass, FixedOffsetTimeZone: TimeZone.

TimeZone can be an interface instead, with two separate implementations: FixedOffsetTimeZone and RegionTimeZone. We could split the time zones by what identifier they have:

• IANA tzdb identifiers, like Etc/UTC or Europe/Berlin,
• and generic identifiers like GMT+01:30.

An upside is that a RegionTimeZone would always have a valid IANA timezone database identifier, guaranteed to be recognized everywhere: see #222. A downside is that Etc/UTC is also semantically a fixed-offset time zone, but wouldn't be marked as such. Also, something like Etc/UTC is not even a region, so maybe another name is needed.

[kevincianfarini]

Do the names NamedTimeZone and AnonymousTimeZone fit here? The former would be an entry in tzdb, and the latter would essentially just wrap a UtcOffset.

Thanks for taking a look into this!

[straight-shoota]

The current model is pretty good and correlates with well defined terms in the time zone handling.
The general concept is called a time zone. A fixed-offset time zone is considered a specialization.

From a programmer's perspective, fixed-offset is simpler and has less features than a dynamic offset, which might suggest the inheritance should be inverted. But from a domain modeling perspective, this doesn't really make sense.
Every time zone has a name and maps an offset to any specific instance of time. That name can be an IANA identifier or not. The offset can be always the same or not.