Announcement Is Not Availability

One product, four dates, one headline

Ask when a product was released and you will usually get the announcement date, because that is when the coverage happened. It is also, for most physical products, the least useful of the four dates involved and often the furthest from when anyone could actually obtain the thing.

The four dates are announcement, pre-order or on-sale, ship or street date, and general availability. They can be the same day. For a software update they usually are. For hardware, collectibles, vehicles and anything supply-constrained they can span a year, and each one is the relevant date for a different person.

A release calendar that records only one of these is answering a question nobody asked. The fix is not more precision about which date is 'real' — it is recording all of them as separate events with their own types.

What each date is good for

Announcement is the date the product becomes known. Specifications published here are provisional and change before shipping more often than people expect. Its practical value is planning: it tells you something exists and roughly when, which is enough to decide whether to wait.

Pre-order or on-sale is the first date on which you can commit money, and for limited products it is the only date that determines whether you get one. This is the date most likely to require action and least likely to be reported prominently.

Ship or street date is when units reach buyers. For pre-orders this can be months after the commitment, and it is the date that slips most often. General availability is when you can walk in and buy one without a queue — for a supply-constrained product this can be a year after launch, and it is the date most people actually care about without realising it is different from the others.

• Announcement — it exists; specifications provisional.
• Pre-order / on-sale — the commitment window; the deadline that matters for limited runs.
• Ship / street date — units reach buyers; the date most likely to move.
• General availability — buyable on demand; often much later, rarely reported.

Why dates slip in one direction only

Release dates move later. They almost never move earlier, and when they do it is a marketing decision rather than a production one. This asymmetry is structural: an announced date is a forecast made before the remaining work is fully understood, and forecasts made under those conditions are optimistic in a consistent direction.

This has a practical consequence for anyone reading a calendar. A date more than six months out should be read as a quarter, not a day. A date announced before a product has been demonstrated publicly should be read as an intention. Only dates inside about eight weeks, for products that have been shown working, behave like commitments.

The corollary is that the number of times a date has already moved is a better predictor than the current date. A product on its fourth announced date is not four times less reliable than one on its first — it is in a different category entirely.

Keep the history, not just the current value

The instinct when a date changes is to update the record. This is wrong, and it destroys the most useful information the record contains.

If a ship date is overwritten each time it moves, the entry always looks confident and always looks like it was accurate right up until it changed. Keeping each revision as its own dated event preserves the pattern, and the pattern is what lets you judge the current estimate.

This applies well beyond hardware. Film release dates, game launches, crowdfunded product fulfilment and book publication all move, and in every case the sequence of announced dates is more informative than the latest one. Storing revisions as events rather than edits costs nothing and is the difference between a record and a snapshot.

Regional staggering is not a detail

Global simultaneous release is rare outside of digital distribution. Physical products roll out by territory over weeks or months, driven by manufacturing allocation, certification, distribution agreements and local retail calendars.

A calendar that records a single global date is therefore wrong for most of its readers most of the time, and confidently so. The right structure is one entry per territory where they differ, or a single entry with the territory recorded explicitly — either is honest, whereas an unqualified date is not.

This matters more than it sounds for anything supply-constrained, because early territories absorb the initial production run. A launch date in one market and availability in another can be separated by an entire product generation in extreme cases.

Reading a release calendar properly

Three habits make the difference. First, always ask which date you are looking at, and treat an unlabelled date as an announcement date until proven otherwise — that is the default that coverage produces. Second, check the territory, because a date without one is incomplete rather than global. Third, look for the revision history before trusting a forward-looking date at all.

Applied consistently, these turn a release calendar from a list of headlines into something you can plan against. The information was always there; it was just collapsed into a single date by the time it reached you, and collapsing it is what made it useless.