How is daylight saving time accounted for in "daily activity" charts?


I noticed something when DST was enabled in my time zone over last weekend.

In 2023 I have these 6 scrobbles (3 from January, 3 from March), with the following UTC timestamps (exported from with user.getRecentTracks API method):

1674238404 == Fri, 20 Jan 2023, 19:13:24 CET
1674238967 == Fri, 20 Jan 2023, 19:22:47 CET
1674239627 == Fri, 20 Jan 2023, 19:33:47 CET

1679835921 == Sun, 26 Mar 2023, 15:05:21 CEST
1679836483 == Sun, 26 Mar 2023, 15:14:43 CEST
1679837071 == Sun, 26 Mar 2023, 15:24:31 CEST

CEST is “summer time” (DST active), CET is “normal time” (no DST).

These don’t show up in my daily activity chart like I expected. Note how the three “Friday” listens fall into “20” square - when in fact they should be in “19” square, as they were listened between 19 and 20:

I don’t have a screenshot for you, but when I first submitted these “Friday” listens DST was still off, and the listens were shown in “19” square. They moved to “20” square over the weekend when DST was activated in my time zone.

Also note how the three “Sunday” listens are in expected square (“15”).

This is not easily visible with bigger number of listens, it took me a while to prepare this minimal example. I hope it demonstrates my observation clearly. Is this a bug, or maybe I’m misunderstanding how this should be working?


Sadly, our timezone, let alone DST support is still a work in progress – as of right now it is non-existant, but should be coming in the next few weeks.

The only thing the timezone setting is used for right now is to determine when we should create the daily-jams recommendations for our users (their midnight).

Stay tuned, we will improve this soon!


So it’s not a bug, just a lack of feature. :slight_smile:

I’m sure you will, there’s been great progress in recent months already.



And we’ve got bushes more stuff to get out the door – the UI revamp is looking really good already. After that we’ll start pushing out some more/improved features.