fix(python!): use time zone from dtype to overwrite output time zone when initialising Series

[MarcoGorelli]

closes #10662

I think this should probably follow what currently happens for dt.strptime

So, the following two should return the same result:

print(pl.Series([dtm], dtype=dtype))
print(pl.Series([dtm_string]).str.strptime(dtype))

---

Unfortunately, to make behaviour consistent, this does involve a breaking change. My fault for not having noticed the inconsistency earlier really - anyway, here it is:

before:

In [9]: pl.DataFrame({'a': [datetime(2020, 1, 1)]}, schema={'a': pl.Datetime('us', 'Asia/Tokyo')})
Out[9]:
shape: (1, 1)
┌──────────────────────────┐
│ a                        │
│ ---                      │
│ datetime[μs, Asia/Tokyo] │
╞══════════════════════════╡
│ 2020-01-01 09:00:00 JST  │
└──────────────────────────┘

In [10]: pl.Series([datetime(2020, 1, 1)], dtype=pl.Datetime('us', 'Asia/Tokyo'))
Out[10]:
shape: (1,)
Series: '' [datetime[μs]]
[
        2020-01-01 00:00:00
]

In [11]: pl.Series(['2020-01-01']).str.strptime(pl.Datetime('us', 'Asia/Tokyo'))
Out[11]:
shape: (1,)
Series: '' [datetime[μs, Asia/Tokyo]]
[
        2020-01-01 00:00:00 JST
]

Now:

In [1]: pl.DataFrame({'a': [datetime(2020, 1, 1)]}, schema={'a': pl.Datetime('us', 'Asia/Tokyo')})
Out[1]: 
shape: (1, 1)
┌──────────────────────────┐
│ a                        │
│ ---                      │
│ datetime[μs, Asia/Tokyo] │
╞══════════════════════════╡
│ 2020-01-01 00:00:00 JST  │
└──────────────────────────┘

In [2]: pl.Series([datetime(2020, 1, 1)], dtype=pl.Datetime('us', 'Asia/Tokyo'))
Out[2]: 
shape: (1,)
Series: '' [datetime[μs, Asia/Tokyo]]
[
        2020-01-01 00:00:00 JST
]

In [3]: pl.Series(['2020-01-01']).str.strptime(pl.Datetime('us', 'Asia/Tokyo'))
Out[3]: 
shape: (1,)
Series: '' [datetime[μs, Asia/Tokyo]]
[
        2020-01-01 00:00:00 JST
]

[MarcoGorelli]

'ETC' isn't a valid time zone, but this never errored because before it was being ignored

[ritchie46]

Yes, we definitely need this one in 0.19!

[ritchie46]

@MarcoGorelli does this need to remain in draft? Seems like the right way to go. If a user provides a datetype, we must respect it.

[MarcoGorelli]

Thanks - what's slightly bothering me is if someone mixes tz-naive and tz-aware values, e.g.:

In [5]: pl.Series([datetime(2020, 1, 1), datetime(2020, 1, 1, tzinfo=ZoneInfo('US/Pacific'))], dtype=pl.Datetime('us', 'Asia/Kathmandu'))
Out[5]: 
shape: (2,)
Series: '' [datetime[μs, Asia/Kathmandu]]
[
        2020-01-01 00:00:00 +0545
        2020-01-01 08:00:00 +0545
]

am I'm not sure that the second value would be expected to most users. It's essentially done "convert to UTC, and then replace the time zone with what the user passed".
Though maybe this is rare enough, and users working with mixed tz-naive and tz-aware objects are kind of playing with fire anyway

[ritchie46]

Though maybe this is rare enough, and users working with mixed tz-naive and tz-aware objects are kind of playing with fire anyway

Using mixed timezone datetime objects AND setting a time zone on a dtype. Might be even juggling with fire. ;)