Simplify timestamp parsing

[akx]

As mentioned in #2972 (comment):

_parse_timestamp_with_tzinfo() already attempts to do fromtimestamp parsing; not much point in doing that work twice for timestamp-esque strings (and failing in the cases described in #2972).

In the subsequent commits, this PR also cleans up remaining seemingly Useless Use of tzlocal.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.15%. Comparing base (8fd0160) to head (3575969).
Report is 120 commits behind head on develop.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3063   +/-   ##
========================================
  Coverage    93.14%   93.15%           
========================================
  Files           66       66           
  Lines        14237    14219   -18     
========================================
- Hits         13261    13245   -16     
+ Misses         976      974    -2     

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

[akx]

@nateprewitt I have some tests you seem to have added for #1987 failing with this (hence a draft), but you might have some context to help here: Why do we need tzlocal or tzwinlocal in the first place?

parse_timestamp doesn't necessarily guarantee the returned datetime should have any tzinfo attached, though the tests seem to always assume it's UTC, and practically, parsing any timestamp off the wire does prescribe a timezone in some way (GMT for RFC822, Z for ISO8601).

Might I be right in guessing the tzlocal/tzwinlocal stuff could actually be all removed in favor of _epoch_seconds_to_datetime's arithmetics?

[akx]

... to follow up on my last comment: one way to find out! (Remaining) tests seem to pass fine, and this is about 28% faster for a benchmark of common values passed in to this function.

(I have another commit – for a future PR – to stack on this that will further increase parsing performance for common cases about 23x compared to develop.)

[akx]

(Gentle review nudge, @nateprewitt? 😄)

[akx]

Another nudge, @nateprewitt... I noticed you'd said

we still have some concerns around the original windows issue that lead to that PR. It's likely safe to clean up as you've suggested but we'll need to do some manual testing first.

in #3062 – anything I can do to help things along?

[akx]

Sorry for Yet Another Ping, @nateprewitt 😅

[akx]

Another ping... @nateprewitt?

[akx]

Rebased post conflicts from #3206...