RescueTime -> ActivityWatch Sync

A small script to import your historical RescueTime activity data into a local ActivityWatch bucket.

NOTE: This was vibe-coded with GPT-5. I make no guarantees about correctness, durability, or the safety of your existing ActivityWatch data. Review the code before use and back up anything important.

What it does

• Calls the RescueTime API (interval perspective) for each day in a date range.
• Chooses the best available resolution (tries minute, then 5min, then hour).
• Transforms rows into ActivityWatch events (timestamp, duration, data).
• Creates (or reuses) a bucket rescuetime.activity in your local ActivityWatch server.
• Incrementally syncs only new events using a state file (.rescuetime_sync_state.json).

Requirements

• Python 3.9+
• An active local ActivityWatch server (default: http://127.0.0.1:5600).
• RescueTime API key (export from your RT account settings) — premium needed for minute resolution.
• requests library (pip install requests).

Installation

pip install requests

(Or add it to your environment/requirements as you prefer.)

Usage

export RESCUETIME_API_KEY=YOUR_KEY
python sync_rescuetime_activitywatch.py --start 2024-01-01 --end 2024-12-31 --resolution minute --tz UTC --verbose

Subsequent incremental sync (uses last synced end timestamp from state file):

python sync_rescuetime_activitywatch.py --resolution minute --tz UTC

Dry run (fetch & transform only, no writes):

python sync_rescuetime_activitywatch.py --start 2025-01-01 --end 2025-01-07 --dry-run --verbose

Arguments

Flag	Description
--start	Start date (YYYY-MM-DD). If omitted uses last synced date or today.
--end	End date (inclusive). Defaults to today.
--resolution	Desired RT resolution `minute
--tz	IANA timezone (e.g. Europe/Berlin) for naive timestamps.
--since	Override stored last synced end timestamp (ISO).
--aw-url	ActivityWatch base URL (default http://127.0.0.1:5600).
--dry-run	Do not write events.
--verbose	Debug logging.

How events are mapped

RescueTime row headers are lowered and placed inside data (e.g. activity, category, productivity, document, people, details, source). Duration is the time slice in seconds. timestamp is the interval start.

State & Idempotence

• The file .rescuetime_sync_state.json stores last_synced_end.
• Rows with timestamp <= last_synced_end are skipped on subsequent runs.

Safety & Caveats

• No guarantee of idempotent dedupe beyond the simple last_synced_end cutoff.
• If your RescueTime data changes retroactively, earlier intervals will not be updated unless you delete the bucket/state and re-import.
• Back up ActivityWatch data (aw-server data dir) before large imports.
• Large historical imports may be slow; script sleeps ~0.7s between days.

Reset / Re-import

1. Delete the bucket via UI or API, or rename BUCKET_ID in the script.
2. Remove .rescuetime_sync_state.json.
3. Re-run with desired --start / --end.

Extending

Ideas:

• Add productivity score mapping / filtering.
• Add parallel fetching with rate-limiting.
• Support partial-day incremental sync (currently day-based API calls).
• Add optional tag normalization or category remapping.