Doctest failure when passing tz-aware datetime to a conversions/ date utility in thealgorithms/Python

Goal

I am working with the date/timestamp conversion utilities in the conversions/ directory of thealgorithms/Python and want to handle regional time zones correctly. My precise goal is to convert a Unix timestamp into a localized date string for a specific IANA zone (for example Europe/Berlin) using zoneinfo, while keeping the repo's doctest-based validation passing.

Constraint and uncertainty

The existing conversion functions appear to assume naive datetimes and fixed format strings, and their doctests only exercise naive inputs. When a tzinfo-aware datetime is supplied, the expected-output doctests no longer match, which causes a pytest doctest failure — the project's primary correctness gate per its contributing guidelines. It is unclear whether the intended contract is that callers must pre-convert to UTC and pass naive values, or whether aware input is simply unsupported.

Assume a recent master checkout and Python 3.11+; behavior may be commit-sensitive since the repo has no stable releases.

Questions

• Is mixing tz-aware datetimes into these conversion functions considered out of scope, with naive-UTC input the documented expectation?
• If I extend a converter to accept zoneinfo-aware input, what doctest output convention should I follow so the CI doctest run stays deterministic across machine time zones?
• Should invalid or ambiguous local times (DST gaps) raise ValueError, given error handling is inconsistent across files?