Repository navigation
Replace custom time handling with datetime/timedelta #1336
Description
Activity
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. If this is still relevant, please comment to keep it open.
Would be nice to have — PRs welcome to swap the raw
time.time()/time.sleep()inexponential_backoff.pyfordatetime.timedelta.Adding a datapoint from the recent cloud-schedule parsing work in #1875:
datetime_helpers.parse_datetimehad to grow a secondstrptimebranch to accept the Cloud form2026-08-29T16:55:00-0700alongside Server's...Z.datetime.fromisoformatwould collapse both into a one-liner — but not until we drop 3.10:- Python 3.11+ accepts both
...Zand unpunctuated offsets like-0700natively. - Python 3.10 rejects
Zand requires punctuated offsets (-07:00), so the swap would still need a preprocessing shim — no cleaner than the current two-strptime pattern.
Once
requires-pythonbumps past 3.10 (EOL 2026-10),parse_datetimebecomesdatetime.fromisoformat(s)andTABLEAU_CLOUD_DATE_FORMAT/ thetry/except ValueErrorfallback can be deleted. Flagging so it doesn't get lost.- Python 3.11+ accepts both
Closing as won't-fix rather than stale. On closer inspection (see #1876) the refactor turns out to be cosmetic —
(datetime.now() - self.start_time).total_seconds()works the same way astime.time() - self.start_time, nothing downstream uses timedelta types, both APIs are equally subject to wall-clock jumps. Sorry for the earlier "PRs welcome" mixed signal.
From #1299:
The use of a custom datetime module caught me off guard in the project.
I'd suggest using datetime and timedelta as the source for seconds and minutes instead of manually keeping track of what the seconds and minutes ought to be, but didn't want to make any more changes than necessary to fix the problem.