Replace all uses of utcnow with tz-aware datetimes

[brandon-doist]

Needed so we emit no warnings when running on python 3.12 systems.

AFAICT, these datetimes are mainly just used to determine redis keys, where the naive/aware makes no difference, and the previous "naive" datetimes were all implicitly UTC anyways (via utcnow).

However, this does change period_start and period_end to return aware datetimes, which is technically breaking!

If you folks notice anything beyond that, please let me know and I'll take a look 🙂

PR Overview

This PR updates all datetime usages to be timezone‐aware, replacing instances of datetime.utcnow() with datetime.now(tz=timezone.utc) to prevent warnings on Python 3.12 systems. Key changes include:

• Adding timezone.utc to datetime calls in tests and production code.
• Adjusting datetime.strptime results to be tz-aware.
• Updating documentation and test examples to use tz-aware datetimes.

Reviewed Changes

File	Description
test/test_cohort.py	Updated datetime instances to be tz-aware in fixture definitions.
test/test_bitmapist.py	Replaced utcnow() with now(tz=timezone.utc) in multiple test cases.
bitmapist/cohort/init.py	Made start_date conversion tz-aware by using .replace(tzinfo=timezone.utc).
bitmapist/init.py	Consistently updated datetime calls and type annotations to use tz-aware datetimes.
test/test_period_start_end.py	Modified test instances to include a timezone in the datetime constructors.
test/conftest.py	Updated deprecated pytest.yield_fixture to pytest.fixture.
test/test_from_date.py	Adjusted test cases to pass tz-aware datetimes to event constructors.
README.md	Updated examples to demonstrate creating tz-aware datetime objects.

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

[goncalossilva]

Changes look great, and tests pass!

I'm not a bitmapist expert but it's not clear to me that the change to period_start and period_end have a practical impact, considering they were naive but running on a machine whose tz is most likely set to UTC. I may be missing something, but I think the result is the same. :)

[brandon-doist]

I'm not a bitmapist expert but it's not clear to me that the change to period_start and period_end have a practical impact, considering they were naive but running on a machine whose tz is most likely set to UTC. I may be missing something, but I think the result is the same. :)

@goncalossilva Yeah, in terms of todoist, I agree with you! I don't even think we reference period_start or period_end anywhere in our code. But this is a public library, so in theory others (with different server configurations) might be, so I thought it'd be worth pointing out still

(it'll be released under a new version, right, so it's not like we're going to surprise-break things on anyone, I hope)

[amix]

The changes look good from my POV. Thanks, @brandon-doist 👏

[brandon-doist]

TY for the review @amix !