[Bug]: wrapped shows incorrect times when running commands in multiple timezones

[printfn]

What did you expect to happen?

When I run atuin wrapped, I expect it to accurately show what (local) time I usually run commands, despite currently being in a different time zone than usual.

I'm usually in UTC+12/+13, running commands during the day (say around 3pm). At the moment I'm in UTC+1, but when I run atuin wrapped it should still say 3pm, since that was the local time when I was using my computer.

What happened?

I received the output:

🕘 Most Productive Hour: 03:00 (6118 commands)
  You're quite the night owl! 🦉

This is incorrect, because atuin converted all timestamps to my new local time zone, rather than keep the original time zone.

Fixing this bug requires atuin to store timestamps with time zone information, rather than just UTC. It can then work out the local time when each command was run, and use that to work out the most productive hour.

Git does the same thing: commit timestamps also store the time including timezone.

Atuin doctor output

Atuin Doctor
Checking for diagnostics


Please include the output below with any bug reports or issues

{
  "atuin": {
    "version": "18.4.0",
    "sync": {
      "cloud": true,
      "records": true,
      "auto_sync": true,
      "last_sync": "2024-12-29 19:17:32.163189 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "zsh",
    "default": "zsh",
    "plugins": [
      "atuin"
    ],
    "preexec": "built-in"
  },
  "system": {
    "os": "Darwin",
    "arch": "arm64",
    "version": "15.2",
    "disks": [
      {
        "name": "Macintosh HD",
        "filesystem": "apfs"
      },
      {
        "name": "Macintosh HD",
        "filesystem": "apfs"
      }
    ]
  }
}

Code of Conduct

• I agree to follow this project's Code of Conduct

[printfn]

This bug can easily be reproduced by running e.g. TZ='Pacific/Auckland' atuin wrapped and TZ='UTC' atuin wrapped. Both invocations should show the same hour as being the most productive.