Skip to content

Comments

fix: handle tz-aware datetimes in naturalday and naturaldate#297

Open
bysiber wants to merge 1 commit intopython-humanize:mainfrom
bysiber:fix-naturaldate-tz-aware
Open

fix: handle tz-aware datetimes in naturalday and naturaldate#297
bysiber wants to merge 1 commit intopython-humanize:mainfrom
bysiber:fix-naturaldate-tz-aware

Conversation

@bysiber
Copy link

@bysiber bysiber commented Feb 21, 2026

Fixes #152

When a tz-aware datetime is passed to naturalday() or naturaldate(), the functions now compute "today" in the datetime's timezone instead of using the system's local date.

For example, if the current UTC time is 2023-10-15 23:00 and you pass a datetime in AEDT (+11:00) where the local date is already Oct 16th, the comparison should use Oct 16th as "today" for that timezone. Previously the timezone was stripped and compared against the system local date, which gave wrong results when the tz-local date differed from the system date.

The fix checks whether the value is a tz-aware datetime and, if so, calls datetime.now(value.tzinfo).date() instead of date.today(). The existing behavior for naive datetimes and plain date objects is unchanged.

Test included using the exact scenarios from the issue.

When a tz-aware datetime is passed to naturalday() or naturaldate(),
the date comparison should use 'today' in the datetime's timezone
rather than the system's local date.

Previously the timezone was stripped and the date compared against
dt.date.today(), which could yield wrong results (e.g. returning
'tomorrow' when the local date in the given timezone is actually
the same day).

Fixes python-humanize#152
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

naturaldate() gives the wrong answer for tz-aware datetimes

1 participant