Skip to content

Feature Request: Make datetime intervals timezone aware #2

Open

Description

@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.

Activity

  1. d2718nis commented on Oct 23, 2024

    @d2718nis
    Author

    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.

  2. d2718nis commented on Oct 23, 2024

    @d2718nis
    Author

    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.

  3. smemsh commented on Oct 23, 2024

    @smemsh
    Owner

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

  4. d2718nis commented on Oct 23, 2024

    @d2718nis
    Author

    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.

  5. smemsh commented on Oct 24, 2024

    @smemsh
    Owner

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions