search

Kotlin / kotlinx-datetime

KotlinX multiplatform date/time library
Apache License 2.0
2.37k stars 97 forks source link

Consider introducing a separate `RegionTimeZone` class #326

Open dkhalanskyjb opened 9 months ago

dkhalanskyjb commented 9 months ago

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:

An upside is that a RegionTimeZone would always have a valid IANA timezone database identifier, guaranteed to be recognized everywhere: see https://github.com/Kotlin/kotlinx-datetime/issues/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 commented 8 months ago

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 commented 8 months ago

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.