krateng / maloja

Self-hosted music scrobble database to create personal listening statistics and charts
https://maloja.krateng.ch
GNU General Public License v3.0
1.06k stars 63 forks source link

Pulse and /scrobbles are set to UTC by default despite system and docker time-zones and without user-visible zone info #317

Open Bujiraso opened 6 months ago

Bujiraso commented 6 months ago

Requested Fix

Please interpret the web-user or system's time-zone (developer's choice) instead of using UTC when presenting scrobble data.

At minimum, append 'UTC' to the date strings if they cannot be immediately converted.

Background

I just scrobbled these two tracks manually

image

But that's not my time, nor is there any timezone.

So these should be showing either zone information, to let the user know what to interpret or -- better -- show the times in the user's or the system's zone. Either is acceptable as a first pass. UTC only without any listed zone information is the worst case :skull:

For reference, the time in UTC was this

When I spotted the issue I grabbed this screenshot to help prove that the above is definitely in UTC

image

The top page, including Pulse correspondingly shows incorrect data, up to the year level

If I scrobble something in my timezone at Dec 31, 2023 11:00 (I'm in a negative timezone), I get something where it erroneously shows in 2024. image

The database shows all correct timestamps

sqlite> SELECT * FROM scrobbles ;
1704289920|{"track_artists": ["BLACKPINK"], "track_title": "Kill This Love", "album_title": "Kill This Love", "scrobble_time": 1704289920}|client:browser||10526|{"album_title": "Kill This Love", "album_artists": ["BLACKPINK"]}
1704290353|{"track_artists": ["BLACKPINK"], "track_title": "Don't Know What to Do", "album_title": "Kill This Love"}|client:browser||10527|{"album_title": "Kill This Love", "album_artists": ["BLACKPINK"]}

These are the correct timestamps. We are 1704290850 now, as of typing, the difference is 930 (seconds) -- so the 15m it's taken me to collect details :stuck_out_tongue: Nothing to change in the database :+1: :tada:

Same thing for the one input near the change of year -- nothing to do in the DB.

System Environment

Within the docker environment, here's the date context

# date
Wed Jan  3 09:22:14 EST 2024
# echo $TZ
America/New_York

And within the outer system

$ date
Wed 03 Jan 2024 09:23:08 AM EST

All zoned and good there!

krateng commented 6 months ago

Check your settings page - you can change the UTC offset.

yashaskm11 commented 6 months ago

UTC offset in the settings page takes only integer and discards any decimal values, this is problematic for zones that have 3.5, 5.5 or similar offset (#247). While setting it manually in the settings file works just fine.

Bujiraso commented 6 months ago

Check your settings page - you can change the UTC offset.

Ah! I can confirm that, after adding my offset, the Pulse data recomputes properly and things look good.

Is there any reason this cannot automatically pick-up any of the TZ offsets on the system? As a user, I expect for it to guess from what the underlying OS is already telling.

Is there any spot in the docs where this is described already? If not, it would be worth adding this there. Especially since it seems to need a full server restart before anything changes.

Automatic detection & docs notes would be a fix on this one to me!