Just noticed however that ActivityWatch is showing timestamps with a “+00:00”, meaning that I have to lie when I get datetime.now() by subtracting my timezone difference from Greenwich.

This shouldn’t be necessary as long as you send a “+01:00” in your timestamps as defined by the iso8601 standard. The response will be UTC, but your request can be in your local timezone and will be filtered correctly.

BilLOPGVkPPn8z0JGJhg:

Shouldn’t ActivityWatch be using timezone aware timestamps? Or just naive ones since the API is limited to localhost right now.

We discussed this a couple of years ago and decided that it should not. Timezones can make things very complicated. If someone for example travels to a different timezone it would mean that they could go back in time and have intersecting events in the same bucket making a timeline visualization completely broken. Having to support such odd scenarios is not in our interest.

We decided instead that it’s better if aw-server is not timezone aware and instead let the visualization in the web-ui depend on your current timezone.

Yeah, timezones always complicate things. I’ve resorted to just querying with a time range of 3 days and filtering timestamps myself with some datetime comparison logic because it’s difficult to confidently get an hour gap for example. If I can never figure it out I’ll ask another time.

johan-bjareholt:

We decided instead that it’s better if aw-server is not timezone aware and instead let the visualization in the web-ui depend on your current timezone.

Shouldn’t it be the other way around? Unless I’m misunderstanding you (I’m interpreting “not timezone aware” as naive datetimes), it seems to me that the backend should be timezone aware and the frontend show everything in local time. So wherever a user goes the backend records everything in UTC, and the UIs convert that to whatever timzeone the user is in. So there’s no “timetravel” going on so to speak.

Shouldn’t it be the other way around? Unless I’m misunderstanding you (I’m interpreting “not timezone aware” as naive datetimes), it seems to me that the backend should be timezone aware and the frontend show everything in local time. So wherever a user goes the backend records everything in UTC, and the UIs convert that to whatever timzeone the user is in. So there’s no “timetravel” going on so to speak.

Timestamps are normalized to UTC before being stored. So they are technically timezone aware, it’s just that the only timezone they are aware of is UTC (so no “timetravel” going on). We’ve discussed making the datastore handle other timezones, but it is not a priority.