It looks like having TimeZone and FixedOffsetTimeZone be @Serializable is more trouble than it's worth, so we plan to deprecate it.

Currently, they get serialized by simply taking their id: String. This approach is not fully reliable.

• New timezone identifiers occasionally get introduced to the timezone database (and sometimes, removed). If some system serializes a new timezone identifier and sends it over to a system that doesn't have an up-to-date timezone database, this will result in an error during deserialization.
• Even if both systems know a specific timezone identifier, they don't necessarily associate it with the same timezone rules. This means that an object serialized on one system will behave differently on another one once deserialized.

Providing the Serializable implementation for TimeZone and FixedOffsetTimeZone hides these issues behind an innocent-looking interface. We would like to have client code implicitly manipulate the identifier strings instead. This is less convenient, but it shifts the place where problems occur from the hard-to-tweak serialization internals to fully controlled client code, which allows flexibly reacting to the problem.

An elegant alternative would be to add a @Serializable timezone identifier as a separate entity to separate identifier syntax validation from querying the timezone database. Despite being entirely reasonable, this approach looks seems non-viable, as the naming rules of timezone identifiers are too lenient to allow us to implement useful validity checks. The closest to a timezone identifier grammar that someone got is https://tc39.es/proposal-temporal/#prod-TimeZoneIANAName, and it allows clearly broken identifiers like dkhalanskyjb, nice_orange_chicken.2009, and Yes/no+maybe.