Remove the python-dateutil dependency

[miketheman]

Description of changes:

Replaces every dateutil usage with stdlib, then drops the requirement.
Please review commit by commit. Each pair (test, then refactor) handles one piece on its own.

Why

dateutil.tz and dateutil.parser gave us timezone and string parsing.
Python 3.10+ stdlib (datetime, email.utils) handles every input shape we actually see.
Removing dateutil also removes its transitive six dep - one fewer thing for packagers
and security scanners to vet on every release.

(Note: botocore still carries a vendored version of six - that is out of scope of this change, and may come later)

Review order

Tests first, then refactor:

1. test: replace dateutil.tz.tzlocal
2. refactor: replace dateutil.tz.tzlocal
3. test: replace usages of dateutil.tz.tzutc
4. refactor: replace dateutil.tz.tzutc with stdlib
5. test: use consistent datetime fixtures in s3express
6. test: replace dateutil.parser with stdlib
7. refactor: replace dateutil.parser with stdlib
8. chore(deps): remove unused python-dateutil

Behavior change

parse_timestamp of an RFC 822 GMT string returns a datetime with tzinfo=datetime.timezone.utc instead of dateutil.tz.tzutc().
Same instant, different tm_isdst (-1 vs 0). One doc-renderer test was updated to match.

Follow-ups

• botocore.compat.get_tzinfo_options is now a one-line shim.
  The TODO in the function describes the cleanup; it removes a public
  symbol, so it should be considered separately.
• botocore.endpoint._calculate_ttl uses strptime("%Z"), which is
  platform-dependent. email.utils.parsedate_to_datetime would be a
  better fit. Separate concern, may come at another time.

Issue #, if available: Resolves #3070

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.57%. Comparing base (ee748e4) to head (aead776).
⚠️ Report is 286 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    #3715      +/-   ##
===========================================
- Coverage    92.59%   92.57%   -0.03%     
===========================================
  Files           68       68              
  Lines        15634    15801     +167     
===========================================
+ Hits         14477    14627     +150     
- Misses        1157     1174      +17     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[SamRemis]

[Note]

This did pass our all of our test suites when ran locally, including integ tests against live services

[SamRemis]

[Question]

This catches a few non-Smithy shapes but rejects others that dateutil handled. For example, it accepts 06/25/2026 but not 2026/06/25, and 15 Jan 2026 but not January 15, 2026. Why these two formats specifically?

[SamRemis]

[Discussion point]

Starting off with my biggest comment:

We have a specification for what accepted timestamp shapes are, so we should only ever need to accept those for parsing. This PR properly handles all officially supported datetime formats, so theoretically this is a fully safe change to make despite handling fewer formats than dateutil.

There are still a few places that I'm still concerned about breaking:

1. AWS services that are incorrectly returning these values which botocore accepts
2. Non-AWS third party services relying on botocore's overly permissive behavior

It's a bad thing that botocore is so permissive. We have seen AWS service teams test their service with other datetime formats against botocore and seen it work, then be surprised when the same datetime format broke the Java SDK. If we ever want to tighten up this behavior, we have to rip the bandaid off at some point or fully commit to supporting this forever.

One way we could make this a little more cautiously is to start by using this new code path first and emitting a warning when we have to fall back to the old one, then ripping out the legacy path in three months with a minor version bump. What do you think?