fix(web): stop album tracks rendering a 12/31/69 date

[dylanjeffers]

Problem

Tracks inside albums render their date as 12/31/69. Reported by Michael from support email (Slack), with three examples:

• https://audius.co/SIRMYKE/album/cabanne-place-vocals-single
• https://audius.co/chillhopmusic/album/chillhop-essentials-summer-2026
• https://audius.co/hullabalo0/album/celestial-groove-the-new-view-2008-2011

Root cause

The API is returning playlist_contents[].timestamp: 0 for exactly the rows that render as 1969 — a long-standing data condition, not new:

celestial  [(EvGyvNo, 0), (XBxbjPR, 1787595758), (rbNjPNY, 0), (qJp7xva, 0), ...]
UI          Prophecy 12/31/69 | Tommy 8/24/26 | Skullthor 12/31/69 | Jungle Punch 12/31/69

What changed is that the client stopped defending against it. The legacy collection lineup saga only assigned dateAdded when the timestamp was non-zero:

// packages/web/src/common/store/pages/collection/lineups/sagas.js (deleted)
if (times[i]) {
  metadata.dateAdded = dayjs.unix(times[i])
}

leaving it undefined on a zero so the downstream fallback fired:

date: metadata.dateAdded || metadata.created_at

#14178 ("Drop legacy lineup system") rewrote this tan-query-first and dropped the guard, always assigning dayjs.unix(time). dayjs.unix(0) is a truthy object, so the || created_at fallback in both formatMetadata and the mobile CollectionPage became dead code.

Albums only, as reported, because desktop/CollectionPage.tsx picks the column by type — isAlbum ? 'date' : 'addedDate' — and date is the one carrying the dead fallback.

Fix

Restore the intent at the source, so desktop and mobile both pick it up:

dateAdded: time ? dayjs.unix(time) : dayjs(t.created_at)

Note for review

onReorderTracks writes dateAdded.unix() back on-chain. With this change, reordering an affected album persists the track's created_at instead of 0 — a heal rather than a corruption, but it is a write side-effect of a display fix and worth a conscious ack. (The prior code path would have written the 0 straight back.)

No regression test: useCollectionPage has no existing test harness and pulls in the redux store, tan-query and the playback slice, so covering this one-line fallback would mean standing up substantial mocking.

Separate follow-up

Why some playlist_contents entries never get a time written is a server-side question this PR does not address. canonicalizePlaylistEntry in go-openaudio's ETL only emits time when the client sends one, with no block-time default — worth its own look.

Test plan

• tsc --noEmit on packages/web — no errors in collection-page (remaining errors are pre-existing unbuilt-workspace noise)
• Load the three album links above and confirm dates render as the track's creation date rather than 12/31/69
• Confirm a playlist (not album) still shows its "Added" column correctly

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 689e6dd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR