Whenever the skill mentions a time — a storm, a wind advisory, tomorrow's forecast — it now always says which day it means: today, tonight, tomorrow morning, or tomorrow night. Below: one story told four times, then a gallery of more alerts and more ordinary days, each showing the time of day, the weather, and exactly what Alexa says.
Reno, NV has a wind advisory running from 11am to 2am the next morning. Here's what four different customers hear, depending only on when they happen to ask.
No alert, just the regular forecast — but the skill always looks ahead, never back at conditions the customer is already in the middle of.
Every kind of alert falls into one of two patterns: some only say when it ends, others say both when it starts and ends. Either way, the day always comes through clearly.
No alert active — just whichever upcoming day or night has the most notable weather, always ahead, never behind.
For a little while, that evening call had a bug: if the worse weather was the next night rather than tomorrow's daytime, the skill said "tonight" instead of "tomorrow evening" — making weather over a day away sound like it was happening right now.
Fixed, tested, and live.
Branch fix/forecast-forward-window-and-alert-time-context ·
PR #60 (open) ·
deployed as Lambda version 204, both ETHAN and development aliases.
All 42 configured alert types speak one of two sentence shapes: 13 "until" types (never mention a start time, only when it ends — e.g. Tornado Warning) and 29 "from…through" types (speak both a start and an end — e.g. Wind Advisory, Severe Thunderstorm Warning). An alert whose start falls beyond the forward window, or that's already expired, is suppressed entirely and the ordinary forecast plays instead.
The ordinary (no-alert) forecast's window size depends on whether "now" falls in a daytime or nighttime NWS block (~6am–6pm vs 6pm–6am): 3 blocks on a morning check, 2 on an evening check. It always picks the most severe block in that window (Thunderstorm > Snow/Ice > Rain > Wind > Cloudy > Sunny); ties keep the nearer block.
The fixed bug: lambda/forecast.js's forwardLabels labeled blocks by
position alone — the first night-block it saw was always "tonight," regardless of whether "now"
was already night. lambda/timeBlocks.js's dayQualifier (used for alerts)
already branched correctly on this; forwardLabels just never got the same treatment.
Now takes a nowIsDaytime parameter (default true, so the morning-check
case is unchanged); when false, the window's one possible night block always reads
"tomorrow evening."
Verification: full suite 282/282, live-tip-probe.mjs 252/0, plus a dedicated regression test and a direct read of the deployed Lambda's response.