Skip to content

The forecast cycle

An AirDesk demo is one finished run of a few days that never changes. Shown as it is, it would read as an archive to browse rather than a forecast to watch. So every demo carries a simulated clock: a pointer that crosses those days in real time and marks where now sits.

  • The pointer enters six hours after the start of the run and advances one minute per minute, like a wall clock.
  • At 24 hours it returns to its starting point. The data does not move; only the place where now rests on it.
  • Everything left of the pointer is past (already observed, in the demo’s language); the pointer’s exact step is the present, the orange PRESENT chip on the time bar; everything to the right is forecast.

Now is computed on the server every time someone asks for the data, and is never written to a file, because it is a property of the moment you asked — a file holding it would be wrong an instant after it was written. Having the server compute it, rather than the browser, is what makes two people looking at the same demo see the same present, and a screenshot match what someone else is seeing at that moment.

No timestamp is disguised. The hours on the bar, in the series and on the alerts are the real hours of the modelled period, in the domain’s time zone. A continuous clock that hid the 24 h wrap was considered and rejected: it would have left no hour on screen corresponding to a real run, and a screenshot could no longer be checked against anything.

What the wrap does change is what counts as past and what counts as forecast. A peak that read as “still to come” yesterday may read as “already observed” today, and that is exactly what lets you rehearse reading a forecast without waiting real days.

Where What you see
Time bar Six hours of past, the PRESENT chip, the forecast to the right
Forecast section The current cycle and its outlook per receptor
Alerts They only appear; a past alert reads as having happened, a forecast one as expected

The time bar · Forecast