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

**URL:** <https://discuss.python.org/t/pep-615-support-for-the-iana-time-zone-database-in-the-standard-library/3468>\
**Category:** PEPs\
**Created:** [February 25, 2020, 3:34pm UTC](https://discuss.python.org/t/pep-615-support-for-the-iana-time-zone-database-in-the-standard-library/3468 "2020-02-25T15:34:06Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![pganssle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pganssle/32/245_2.png) [@pganssle](https://discuss.python.org/u/pganssle)\
**Post date:** [February 27, 2020, 5:25pm UTC](https://discuss.python.org/t/pep-615-support-for-the-iana-time-zone-database-in-the-standard-library/3468/17 "2020-02-27T17:25:31Z")

</div>

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).

---

_[View the full topic](https://discuss.python.org/t/pep-615-support-for-the-iana-time-zone-database-in-the-standard-library/3468)._