feat(python): Validate time_zone in pl.Datetime

[luke396]

closes #16038

Before

pl.Datetime(time_zone="invalid_time_zone")
# Datetime(time_unit='us', time_zone='invalid_time_zone')

pl.Datetime(time_zone=object())
# Datetime(time_unit='us', time_zone=<object object at 0x7f245331d0d0>)

pl.Series([datetime(2020, 1, 1)], dtype=pl.Datetime(time_zone='cabbage'))
# ComputeError: unable to parse time zone: 'cabbage'. Please check the Time Zone Database for a list of available time zones

After

pl.Datetime(time_zone="invalid_time_zone")
# ValueError: invalid time zone: 'invalid_time_zone', to see valid strings run `import zoneinfo; zoneinfo.available_timezones()`

pl.Datetime(time_zone=object())
# ValueError: invalid time zone: <object object at 0x7f830861fb30>, to see valid strings run `import zoneinfo; zoneinfo.available_timezones()`

pl.Series([datetime(2020, 1, 1)], dtype=pl.Datetime(time_zone='tst'))
# ValueError: invalid time zone: 'tst', to see valid strings run `import zoneinfo; zoneinfo.available_timezones()`

[codecov]

Codecov Report

Attention: Patch coverage is 84.61538% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 80.98%. Comparing base (0b66308) to head (18b43b4).

Files	Patch %	Lines
py-polars/polars/datatypes/classes.py	84.61%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #16165      +/-   ##
==========================================
- Coverage   80.99%   80.98%   -0.01%     
==========================================
  Files        1387     1387              
  Lines      178832   178842      +10     
  Branches     2877     2880       +3     
==========================================
+ Hits       144839   144841       +2     
- Misses      33500    33506       +6     
- Partials      493      495       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[stinodego]

This looks pretty good! I left some comments. Would be nice if @MarcoGorelli could also take a look at this.

[stinodego]

I think we should skip validation in this case, rather than raise an error. I believe working with time zones only requires the zoneinfo package in some specific cases.

[luke396]

Thank you for the advice, I have removed the error.

[stinodego]

Does this match with the list of timezones we use on the Rust side? What are the differences if there are any?

[MarcoGorelli]

This is the part that concerns me a little, I'm pretty sure I encountered some differences

[MarcoGorelli]

Thanks for having worked on this

To be honest I'm a bit hesitant about it - it's already impossible (counterexamples welcome, I might be missing something) to create a column with an invalid time zone

Not sure there's an advantage to adding extra code to make the validation happen earlier, especially if it doesn't quite match how the validation is done at the Rust level

[luke396]

Not sure there's an advantage to adding extra code to make the validation happen earlier, especially if it doesn't quite match how the validation is done at the Rust level

Actually, when I was writing the code, I was concerned about whether it was okay to add extra validation in DataType and what regressions it might produce.

I'm not sure if you noticed this issue comment. What are your thoughts on it?

If we decide to leave the check for later, should we add some notes in the user guide or the method's documentation to clarify that this is what we intend?