Every clock time the skill speaks now carries a day reference — "today," "tonight," "tomorrow morning," "tomorrow night" — so a customer always knows whether something is already happening or still ahead of them. The ordinary forecast also now always looks forward, never repeating back conditions the customer is already in.
All 42 configured alert types speak one of two sentence shapes, verified directly against the code.
| # | Customer calls… | Alert situation | What Alexa says |
|---|---|---|---|
| 1 | 1pm | FROM Wind Advisory (Reno), 11am–2am — already active | In Reno, NV, a wind advisory will be in effect from 11:00 AM today through 2:00 AM tonight, with a high of 68 and a low of 42. |
| 2 | 9am, same day | Same advisory, starts in ~2 hours | …from 11:00 AM today through 2:00 AM tonight… — still "today," since the onset is inside the current daytime block |
| 3 | 9pm the night before | Same advisory, doesn't start until tomorrow | …from 11:00 AM tomorrow morning through 2:00 AM tomorrow night… |
| 4 | Any time | Same advisory, but its start is beyond the forward window (see Table 2) | Not spoken at all. Suppressed entirely; the ordinary forecast plays instead. |
| 5 | Any time | Same advisory, already expired | Not spoken. Expired alerts are filtered out before selection; forecast plays. |
| 6 | 1pm | UNTIL Tornado Warning, already active, ends 2am | In Reno, NV, a tornado warning is in effect until 2:00 AM tonight, with a high of 68 and a low of 42. Note: never mentions when it started, even if it hasn't started yet. |
| 7 | Any time | Two qualifying alerts active at once | Only the higher-severity one is spoken (severity → onset → effective → id tiebreak order); the other is silent this turn. |
Window size depends on whether "now" falls in a daytime or nighttime NWS block (~6am–6pm vs 6pm–6am). Picks the most severe block: Thunderstorm > Snow/Ice > Rain > Wind > Cloudy > Sunny.
| # | Customer calls… | Window available | Worst weather is in… | What Alexa says |
|---|---|---|---|---|
| 8 | 9am (morning check) | tonight / tomorrow day / tomorrow night — today's own weather is never mentioned, even mid-thunderstorm | tonight | …there's a chance of thunderstorms tonight, with a high of X and a low of Y. |
| 9 | 9am (morning check) | tomorrow (day) | …expect [condition] conditions tomorrow morning… | |
| 10 | 9am (morning check) | tomorrow night | …tomorrow evening… | |
| 11 | 9am (morning check) | nothing severe anywhere | Picks the nearest block regardless (defaults to sunny/calm wording) | |
| 12 | 8:30pm (evening check) | tomorrow day / tomorrow night only — tonight's own weather is never mentioned | tomorrow (day) | …expect [condition] conditions tomorrow morning… |
| 13 | 8:30pm (evening check) | tomorrow night | …there's a chance of severe thunderstorms tomorrow evening, with a high of X and a low of Y. — fixed, see below | |
| 14 | Any time | Two blocks tie on severity | The nearer block wins the tie | |
When an evening check's worse weather was in the second block of its 2-block window (i.e. tomorrow night), the code labeled it "tonight" — not "tomorrow night." Traced to an inconsistency between two pieces of logic built separately:
lambda/timeBlocks.js's dayQualifier (used for alerts) correctly
branches on whether "now" itself is day or night.lambda/forecast.js's forwardLabels (used for the ordinary forecast)
did not — it labeled blocks by position alone, always calling the first
night-block it saw "tonight," regardless of whether "now" was already night.Concretely: call at 8:30pm, tomorrow's daytime is sunny, tomorrow night has severe thunderstorms.
Before: "…there's a chance of severe thunderstorms
tonight…" — sounding like right now, when it actually meant over 24 hours
away.
After: "…there's a chance of severe thunderstorms
tomorrow evening…" — correct timing, and still warns about the storms; the
fix deliberately left the severity-based selection alone, so advance notice of severe weather
more than one block out is still surfaced.
forwardLabels now takes a nowIsDaytime parameter (default
true, so the morning-check case is untouched). When false, the window's
one possible night block always gets "tomorrow evening" — the same wording already used for that
relative position in the morning-check case, not new vocabulary.
Added the end-to-end regression test that was missing (an evening check whose worse weather is
the second block, asserting the corrected wording and that "tonight" does not appear), and fixed
the forwardLabels unit test that had been asserting the bug's output as correct.
Full suite: 281/281 pass. Deployed as Lambda version 201, both
ETHAN and development aliases; live-tip-probe.mjs:
252/0 pass.