Introduction

To check whether a datetime occurs today, compare only the date portion, not the full timestamp. The important subtlety is timezone: a moment that is "today" in one timezone may already be "tomorrow" or "yesterday" in another.

Compare the Date Part Directly

In Python, the simplest case is to compare the date() of the value against today’s date:

1from datetime import datetime, date
2
3dt = datetime(2026, 3, 11, 9, 30)
4
5is_today = dt.date() == date.today()
6print(is_today)

This works for naive datetimes that already represent local time in the same timezone context as date.today().

Use the Same Timezone on Both Sides

If the datetime is timezone-aware, convert it to the timezone that defines "today" for your application:

1from datetime import datetime
2from zoneinfo import ZoneInfo
3
4user_zone = ZoneInfo("America/Toronto")
5dt = datetime(2026, 3, 11, 1, 15, tzinfo=ZoneInfo("UTC"))
6
7is_today = dt.astimezone(user_zone).date() == datetime.now(user_zone).date()
8print(is_today)

Without the conversion, you may compare the right instant against the wrong calendar day.

Wrap the Logic in a Helper

If this rule appears in several places, a helper keeps the timezone choice explicit:

1from datetime import datetime
2from zoneinfo import ZoneInfo
3
4def occurs_today(dt: datetime, zone: ZoneInfo) -> bool:
5    return dt.astimezone(zone).date() == datetime.now(zone).date()

This is cleaner than repeating conversion and comparison logic throughout the codebase.

Avoid String-Based Comparisons

You might see code that formats both values as strings and compares them. That works only incidentally and makes timezone reasoning less clear:

today_str = datetime.now().strftime("%Y-%m-%d")
dt_str = dt.strftime("%Y-%m-%d")

Comparing date objects directly is simpler and less error-prone.

Test Boundary Cases Explicitly

Date logic often fails around midnight, daylight-saving transitions, and timezone conversions. A good unit test should include values just before and just after midnight in the target timezone:

1from datetime import datetime
2from zoneinfo import ZoneInfo
3
4zone = ZoneInfo("America/Toronto")
5late = datetime(2026, 3, 11, 23, 59, tzinfo=zone)
6early = datetime(2026, 3, 12, 0, 1, tzinfo=zone)
7
8print(late.date())
9print(early.date())

Testing these boundaries is often more valuable than testing random midday timestamps.

If the source timestamps arrive in UTC, convert them before applying "today" logic. That keeps the business rule tied to the intended calendar, not to the transport format.

This is a good place to write tests against a fixed timezone rather than relying on whatever timezone the CI server happens to use.

Doing that makes date-sensitive bugs reproducible instead of intermittent.

It also documents what "today" means in the application.

That clarity prevents subtle support issues later.

Common Pitfalls

The biggest mistake is comparing a timezone-aware datetime with a naive "today" value. That can shift the calendar day unexpectedly.

Another issue is comparing full datetime objects instead of their date parts. A timestamp at 09:00 today is not equal to datetime.now(), but it still occurs today.

People also forget that server-local time and user-local time are often different. If "today" is user-facing, use the user’s timezone rather than the server default.

Finally, if the input might already be a date object instead of a datetime, handle that consistently instead of calling .date() blindly.

Summary

• Compare the date portion of the datetime against today’s date.
• Use the same timezone on both sides of the comparison.
• Prefer direct date comparisons over string formatting tricks.
• Put the logic in a helper if the rule appears in many places.
• Decide whether "today" means server-local time or user-local time before writing the check.