You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Make datetime intervals timezone aware #2
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.
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.
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.
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.
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.
Activity
d2718nis commentedon Oct 23, 2024
Weirdly enough, my setup seems to be ignoring the
+00:00timezone 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 commentedon Oct 23, 2024
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 commentedon Oct 23, 2024
Out of curiosity, do you work in multiple timezones? Does your import data have more than one timezone?
d2718nis commentedon Oct 23, 2024
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 commentedon Oct 24, 2024
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.