Use dynamic dispatch when converting chrono timezones into python

[bschoenmaeckers]

This fixes #4909 by removing the constraint for Tz to be IntoPyObject and instead using dynamic dispatch, albeit at the cost of some performance.

I'm not sure if we want to go this route in future pyo3 releases and instead require users to implement IntoPyObject for custom TimeZone implementations or let them convert it into a standard chrono one. If so then this PR should be merged into the 0.23 branch only.

[davidhewitt]

Hmm, I think I prefer the static dispatch personally. But I think that this would be also potentially a (silent?) breaking change to backport because it would break any users that have implemented IntoPyObject for their custom Tz types?

So we might be stuck? 😟

cc @kylebarron

[bschoenmaeckers]

I think I prefer the static dispatch personally.

My preference is definitely static dispatch as well.

But I think that this would be also potentially a (silent?) breaking change to backport because it would break any users that have implemented IntoPyObject for their custom Tz types?

IntoPyObject for custom Tz's did not used to work before pyo3 0.23.4 so we would be restoring the original behaviour for custom TimeZone types in 0.23. So it would not be a breaking change for 0.23 but only a fix of a breaking change right?

[davidhewitt]

Yes, but at least the 0.23.3 -> 0.23.4 change was breaking at compile time, merging this would then break the new behaviour silently for any users who are using the 0.23.4 features.

[davidhewitt]

Agreed that 0.23.3 -> 0.23.4 change was unfortunate, though I still think it's better to not thrash it further 😭

[bschoenmaeckers]

Agreed that 0.23.3 -> 0.23.4 change was unfortunate, though I still think it's better to not thrash it further 😭

Sure closing this for now.