Describe the bug
A datetime constraint can be created in Unleash with a timezone-aware or timezone-naive ISO datetime string. If a timezone-aware datetime is used (which appears to be the default for the Unleash web app), the Python client will fail when evaluation that constraint if a timezone-naive datetime object/string is provided as the currentTime in the context. The same is true of the inverse (tz-naive constraint and tz-aware currentTime).

This is mainly an issue if currentTime is not set in the context and the Unleash client provide its own currentTime value. If a user providers a currentTime value themselves, it's reasonable enough to require them to be consistent (all tz-aware or all tz-naive). But currently, if the default currentTime is used, it fails if the constraint is tz-aware.

Logs

TypeError: can't compare offset-naive and offset-aware datetimes