DEPR: timestamp/fromtimestamp tz-naive behavior

[jbrockmendel]

#91384 calls for the datetime docs to be updated to say that timezone-naive datetimes are implicitly localized to the system-local timezone. Such a doc change would be misleading. Parts of the API behave that way (.timestamp, .fromtimestamp), others do not (comparisons, subtraction).

A better fix would be to choose one behavior and stick with it. Because (I assume) it is much much less, .timestamp() should be deprecated on tznaive datetime objects to either a) raise or b) behave as if the object were localized to UTC.

xref #155883 a user thinking the current behavior was a bug

[picnixz]

We will not change it and this was already explained why. We also will not deprecate anything as this will break everyone that properly uses the API

[jbrockmendel]

Can you point me towards this explanation?

[picnixz]

First, my answer may have been a bit too blunt so sorry for that.

I consider this as an explanation: #91384 (comment). The problem is that the API is 12 years old and changing this specific part (whether through deprecation or any different runtime changes) can affect more than one user in unexpected ways.

Now, if you want to push a deprecation forward (or any runtime changes), I would suggest that you open a thread on https://discuss.python.org/c/ideas/6. We can't make that change just because of some "inconsistencies" or "incompleteness" in the docs. I personally think it's a "the ship has already sailed" problem where changing anything would annoy users more than helping them. People relying on the current assumptions would need to migrate their code. And when we break something related to time (in the broader sense), it always bite us later.

Personally, I am against changing the behavior. Consistency at the cost of breaking code is not worth it. For .timestamp(), it does depend on whether it is naive or aware, and the definition of being naive changes, which I agree may be confusing. However, since it's been that way for a very long time, changing it would affect too many users. We are still consistent with .astimezone where the naive datetimes are considered similar.

others do not (comparisons, subtraction).

Those are binary operations and therefore can be act differently. I see methods assuming a different definition of "naive" more as "helpers" while when doing comparisons or binary operations, the objects to be compared to must belong to the same category.

I partially agree that this can be confusing but I disagree that we must pick a side. Acting on the objects themselves (methods) to get some information is a different task than making operations on the categories the objects belong to. If I were to pick a side, I would however choose to indeed deprecate timestamp() and ask users to use localtimestamp() for instance (a new method) or explicitly use something that shows "this naive datetime will be converted to system time first" rather than doing conversions in other operations. But this definitely needs a wider discussion on DPO (we can always improve the docs to help the reader more about what will be implicitly converted and when)