Feature Request: Make datetime intervals timezone aware

[d2718nis]

Issue

When a timezone-aware datetime is passed to the Interval, it formats it as if it as if it were timezone-unaware.

Use Case

I encountered this issue while importing time entries from other time trackers via an API in the format 2024-10-23T12:00:00+00:00, then converting them to timezone-aware datetime objects to feed into python-timew. Since I'm currently in a non-UTC timezone, the times were imported into Timewarrior with incorrect datetime values. While I can apply a local fix in my script, it seems beneficial for the project to natively support timezone-aware datetime values.

Solution

Replace datetime.strftime('%Y%m%dT%H%M%S') with datetime.isoformat(timespec='seconds') which handles both timezone-aware and naive datetime objects. The timespec parameter is used to trim off microseconds (if present), as Timewarrior cannot parse them.

[d2718nis]

Weirdly enough, my setup seems to be ignoring the +00:00 timezone format, even though it's mentioned as valid in the documentation. This could either be a bug in Timewarrior itself or something specific to my configuration.

[d2718nis]

We'll see what the maintainers say about this, but it seems like a Timewarrior bug to me. Until it's resolved on their end, there's no point in adding timezone support (at least by using the .isoformat() method). I'll leave a link to track whether it's confirmed as a bug and when (or if) it's fixed, so this feature can be added later.

[smemsh]

Out of curiosity, do you work in multiple timezones? Does your import data have more than one timezone?

[d2718nis]

Usually, no — I typically just import data from a remote API, most of the time it's in UTC. However, I noticed that the timezone isn't processed correctly, so I checked the source code.

[smemsh]

Your solution looks good, once we figure out that upstream issue you linked, I will accept a PR if you want, and make a release to PyPi. Probably we should add a test for this to interval_test.py.