Your Spotify listening clock: what the hour of day really measures.

A listening clock answers a simple question: at what time of day do you listen? To draw one from a Spotify export you have to decide what to count, which moment of each stream to use, and whose clock to read it against. Get the last one wrong and every bar slides sideways, and nothing on the chart tells you it happened.

One real clock

This is five years of one person's listening, 6,630 hours of it, placed by the local hour each stream started.

00:0006:0012:0018:00

The 24 values behind the chart

Hour	Share of listening time
00:00	4.88%
01:00	4.69%
02:00	4.34%
03:00	3.77%
04:00	3.27%
05:00	2.99%
06:00	2.49%
07:00	2.47%
08:00	2.60%
09:00	2.80%
10:00	3.23%
11:00	3.78%
12:00	3.89%
13:00	4.06%
14:00	4.17%
15:00	4.57%
16:00	4.90%
17:00	5.00%
18:00	5.16%
19:00	5.29%
20:00	5.35%
21:00	5.46%
22:00	5.53%
23:00	5.28%

Three things about that shape are decisions rather than facts, and each is worth knowing before you read your own.

Decision one: count time, not plays

The clock adds up how long you listened in each hour, from the ms_played field, rather than how many tracks you started. A play count rewards restless hours, where you skip through ten tracks in five minutes, and makes them look busier than an hour you spent on one long album. For this listener the two happen to agree: the busiest hour is 22:00 either way. Yours may not.

Decision two: whose clock

The ReadMe Spotify includes in the extended history download describes the ts field as the moment a track stopped playing, in UTC. There is no timezone anywhere in the record. There is a conn_country, which gives the country but not the zone, and cannot tell New York from Los Angeles.

So something has to supply the zone, and Quilore uses the one your browser is set to when you open the file. That choice is the one that matters most. This listener lives one hour ahead of UTC with no clock changes. Read in UTC instead, the chart moves 3.05% of all listening into the wrong hour, and the peak slides from 22:00 to 21:00. One hour of offset is the gentle case. At five hours every bar moves five places, so for someone five hours ahead of UTC a 22:00 peak shows up at 17:00.

The timezone decision moved fourteen times more listening than the start-or-end decision did.

It also means the clock assumes you spent your whole history where you are now. For this listener that is nearly true, since 99% of the time was streamed from one country. If you moved abroad in 2022, everything before the move is drawn in your new zone, and the old routine will look shifted by the difference.

Decision three: start or end

Because ts is the end of a stream, Quilore subtracts ms_played to find when it started, and files the stream under that hour. It is the correct reading, and for an hour-of-day chart it turns out to matter less than you might expect: using the end time instead would move just 0.22% of this listener's time into a different hour. Most tracks are a few minutes long, so start and end usually share an hour. Splitting each stream minute by minute across the hours it actually covered changes even less, 0.11%.

Where it does matter is the calendar. In this export 322 streams, about 16 hours of listening, started before midnight and finished after it. Filed by their end time they would land on the next day, which bends anything built on days, such as the day-of-week chart and the count of days you listened on.

Checking your own

1. Open the files named Streaming_History_Audio in your export.
2. For each entry, take ts, subtract ms_played milliseconds, and convert the result from UTC to the timezone you lived in.
3. Add ms_played to the total for that hour.
4. Leave out entries where incognito_mode is true if you want to match Quilore, which keeps private sessions out of its charts.

If your peak looks an hour or more away from when you know you listen, check the timezone before anything else. It is the likeliest cause by a wide margin.