feat(rust, python): auto-infer fmt for tz-aware date strings

[MarcoGorelli]

closes #7198

check this out

In [14]: data = [
    ...:     "2021-03-27T00:00:00+01:00",
    ...:     "2021-03-28T00:00:00+01:00",
    ...:     "2021-03-29T00:00:00+02:00",
    ...:     "2021-03-30T00:00:00+02:00",
    ...: ]

In [15]: pl.Series(data).str.strptime(pl.Datetime, utc=True).dt.convert_time_zone('Europe/Brussels')
Out[15]: 
shape: (4,)
Series: '' [datetime[μs, Europe/Brussels]]
[
        2021-03-27 00:00:00 CET
        2021-03-28 00:00:00 CET
        2021-03-29 00:00:00 CEST
        2021-03-30 00:00:00 CEST
]

limitations:

• the only format I've added in this PR is '%+', but the list can be expanded later
• this'll take some extra work for it to work in read_csv, but...it should make it possible!

[MarcoGorelli]

One month later, finally marking this as 'ready-for-review' 🎉 @ritchie46 @alexander-beedie in case you have time / want to take a look

[ritchie46]

Thanks @MarcoGorelli. Could you help me a bit with the review. What have you changed? What are expected performance implications and which snippets are the gist of the changes?

[MarcoGorelli]

Sure!

The main thing is that this PR expands Pattern to

 pub enum Pattern {
     DateDMY,
     DateYMD,
     DatetimeYMD,
     DatetimeDMY,
+    DatetimeYMDZ,
 }

to include YMD where an offset is present.

To keep track of the offset, I've also changed return type of infer_pattern_single from Option<Pattern> to Option<PatternWithOffset>.
The latter is just like the former, but also keeps track of the offset:

pub struct PatternWithOffset {
    pub pattern: Pattern,
    pub offset: Option<FixedOffset>,
}

To deal with the offset, I've introduced transform_tzaware_datetime_*s (similar to transform_datetime_*s) which also needs to take a utc argument and an offset argument - so I've added them to transform_datetie_*s too, but prefixed them with underscores as they're unused.

The rest is mostly just updating based on the above.

Just like with parsing with an explicit fmt, multiple offsets are only allowed if utc=True.

I don't think there should be any performance implications. A timing test I've done doesn't show any difference in performance for dates.str.strptime(pl.Datetime) compared with master

[ritchie46]

Thanks for the explanation. This makes the review so much easier. 👍

The code looks good and the rationale of expanding the tz aware functionality make sense, so merging in. Thanks a lot!