@echoboomer would it be possible to get this (or similar fix) in the next release?

@echoboomer I've rebased this and bumped to v1.10.8

Would love to have this one reviewed / merged before I do the confluence one.

Looks like this will need some changes.

https://docs.python.org/3/library/datetime.html#technical-detail

%Z
In strftime(), %Z is replaced by an empty string if tzname() returns None; otherwise %Z is replaced by the returned value, which must be a string.
strptime() only accepts certain values for %Z:
any value in time.tzname for your machine’s locale
the hard-coded values UTC and GMT
So someone living in Japan may have JST, UTC, and GMT as valid values, but probably not EST. It will raise ValueError for invalid values.

Mmmm using %Z in the output format means we won't be able to reparse the time (if it is not UTC or local to the machine time).

This has far reaching implications especially since all timestamps are stored as formatted timestamp strings in the database.

As a short term fix; I think all instances of: datetime.datetime.strptime(inc.created_at, tools.timestamp_fmt) will need to be replaced with a utility function that can correctly parse the stored times. This may involve an additional time parsing library like arrow.

And another problem;

When we do parse the datetime with strptime it will be stored as a timezone naive datetime object. These objects
are then compared against other date time naive objects.
Eg:

https://github.com/echoboomer/incident-bot/blob/4126c4c3e9ba77a1186a9dc256c10a4c4717bf13/backend/bot/scheduler/scheduler.py#L90C1-L97C2

Should I modify this PR to ensure all timezones are datetime aware?