7 July, 2026 – Dan Q

…

The Walkman is the Sony WM-EX521 from 2002, which is a pretty late model. It’s not one of the classics from the 80s, but I really like the design, the case is made out of metal so it looks and feels really solid and with it being relatively young, I don’t expect too many problems. In fact, I had a suspicion that the only thing that was wrong with it might be the belt. Tape drives have rubber belts in them which link the motor with the tape mechanism, and these wear out over time. They can become loose or lose their elasticity, some break and some also try to turn themselves back into crude oil, which leaves a giant mess behind.

So when the Walkman arrived, I opened the back to see how it looked on the inside, which required putting it on a heat plate for a few minutes to soften the adhesive, and then I could carefully insert a plastic tool between the frame and the back cover and start prying… nah, I’m kidding. This was made before all of that nonsense. You take out five screws and you’re in. Which is how it should be.

Anyway, I took the back off, stuck a battery in, pressed play and I could see that the motor was spinning, but the belt was loose and wasn’t moving. Suspicion confirmed, the belt was bad. Thankfully it was just worn out and hadn’t disintegrated yet, so that’s an easy fix.

I ordered a new belt here, which arrived a few days later from Portugal, and replaced the old one. I also sprayed some contact cleaner into the volume potentiometer while I was at it, because it sounded very noisy and scratchy. Here are some pictures, and you can see the old, worn out belt next to the new one. It’s literally twice as long! No wonder it wasn’t working anymore.

…

Andreas (82MHz), in I bought a Sony Walkman

This entire post is amazing. Every step Andreas takes, from selecting and buying an (old) Walkman, to repairing its belt, to using the (known) frequency of the first note of a song to “tune” it by recalibrating the speed control potentiometer while playing into a guitar tuner app… feels like you’re being taken along on the journey with him.

I really enjoy Andreas’ writing style and posts, so I’ll be adding him to the blogroll. A delightful and serendipitous find (courtesy of Bubbles).

On March 8, 2026, British Columbia moved their clocks to a year-round Pacific Daylight Savings Time. In March, they did the spring forward one hour with their clocks to UTC-7, but they won’t fall back to UTC-8 in November. Going forward, the UTC offset for America/Vancouver timezone is permanently UTC-7.

Let’s use this as an opportunity to talk about date and time zone storage. In the most basic examples, the default is to store the UTC value, then calculate local time relative to UTC. However, people using calendar systems think in terms of local time (i.e. wall clock time), and never consider UTC. After modifying time zone data, these time calculations from UTC for a region will differ from the user’s input value.

If you stored timestamps in a UTC-based column for British Columbia-based appointment in 2026 and beyond, your November through March appointments may be off by an hour!

…

Christopher Winslett (Crunchy Data), in British Columbia, Time Zones, and Postgres

A fascinating read into a problem that I knew existed… and fear!

This is the kind of thing that keeps me up at night every time I expand on Three Rings‘ timezone support. Right now, Three Rings stores the times of “shifts” (when volunteers do things) as UTC timestamps but treats them as “local time” to the voluntary organisation using them. If they say a shift starts at 8pm, that’s probably what they mean: they mean 8pm local time, no matter where they happen to be in the world and whether or not their region uses daylight saving time.

But this approach, while simple, has limitations:

Three Rings doesn’t correctly respect shift duration variance as a result of daylight saving time clock changes. Suppose a Samaritans branch has a four-hour shift starting at midnight on Saturday night/Sunday morning. Twice a year, that shift will intersect with the clocks going forwards or backwards. Is it still a “four hour” shift? Well that depends: does the volunteer stay for four hours regardless of the clock change, or do they always go home at 4am? Three Rings assumes the former because it’s mathematically simpler, but in reality the latter is probably true (and the volunteer actually worked three or five hours).
Three Rings isn’t suited to organisations that span multiple timezones. When an Australian charity started using Three Rings they were interested in getting an overview of how many of their helplines – which are spread across three to four timezones (depending on whether daylight saving is in effect: half of central Australia observes daylight savings and half doesn’t!) – are open at any given time. Three Rings currently isn’t designed in a way to make it easy to answer that question.
Three Rings makes some suboptimal choices if you’re a long way from the Prime Meridian. This one’s easier to fix, and we probably will, but if you’re far from the UK and especially if you’re West of the UK then our scheduled tasks to e.g. “lock” shifts that appear to have “started” and prevent their easy modification… triggers at the wrong time.

Items 1 and 2 on that list are hard problems to solve, especially starting from where we are with our vast corpus of 24 years worth of “assumed local” time data. We’re improving on this kind of thing by increments, but it takes a while…

…and then, just sometimes, some country decides to fiddle with its timezone or its observance of daylight saving time and makes programmers’ lives hell.

Still; I’ll be referring to this blog post by Christopher Winslett the next time I’m working on a big set of timezone-related enhancements for Three Rings, for sure!