PEP 615: Support for the IANA Time Zone Database in the Standard Library

[pganssle (Paul Ganssle)]

In some ways, the debate over the proper serialization format is a strange one, because pickle is by its nature an ephemeral serialization format - you will have many problems if you try and use it to serialize between dissimilar environments, so in some ways I’m inclined to neglect the case where the data changes between serialization and deserialization anyway.

In the end, I am not sure what most users would want. I think @stub42 makes some solid points about thinking of it in terms of serializing civil times (I had neglected this because usually I only think of that problem when storing dates for the long term, but it’s a valid one, particularly with the cache behavior).

To me, the strongest argument in favor of serializing “by value” rather than “by reference” is that if we go with serializing “by value”, end users on either end of the equation have the option of getting the “by reference” behavior on their own, whereas if we go with “by reference”, end users can’t implement a “by value” solution on their own. I actually really like the idea of doing something like @guido’s solution:

@guido

I wonder if you could have an opaque RawZoneInfo object that behaves like a nocache ZoneInfo and is pickled by value, and have regular ZoneInfo be a very thin wrapper for that (maybe a subclass with no extra fields) but with by-key pickle behavior?

Exposing some interface to get the raw data (RawZoneInfo base class seems like the most natural) would basically alleviate my qualms about this entirely, and give a nice, reasonable default behavior for everyone else.

Another option here is to just go with serialization by key in Python 3.9 and if there’s a lot of demand for the feature we can add RawZoneInfo in a later version. Doing so should be backwards-compatible. For people stuck in the middle, dateutil.tz.tzfile will keep the “serialize by value” behavior it’s always had, and people who need that can use dateutil as a stop gap.

So here’s my proposal for what to do with pickling:

1. Normally-constructed ZoneInfo objects are serialized by reference to their key parameter.
2. ZoneInfo.nocache objects are also serialized by reference to their key parameter, but with a flag indicating that they are not drawn from the cache, so they will bypass the cache in the deserialization step.
3. ZoneInfo.from_file objects cannot be pickled. (End users can write wrapper types if they want to serialize them by key).