Why local time changes what “today” means in a weather forecast

One instant, four local clocks

Weather data moves between computer systems most safely as an exact timestamp, commonly expressed relative to UTC. Readers plan in local civil time. A city forecast therefore has to convert each instant into the timezone used by that city before it can label an hour or group values into “today” and “tomorrow.”

World Wide Weather News assigns a full IANA timezone to every approved city: Europe/Berlin, Europe/Moscow, Asia/Tbilisi and America/New_York for the first four pages. These names are more reliable than a fixed label such as “UTC+2” because a named timezone can carry the region’s offset history and daylight-saving rules.

At the same moment, one city can already be on the next calendar date while another is still on the previous one. That is why the website does not apply the editorial timezone to city forecasts. Asia/Tbilisi controls the 06:30 editorial drafting schedule, but each forecast uses its own city timezone.

UTC identifies the instant; the timezone supplies the local label

An hourly forecast row needs both ideas. The stored timestamp identifies one instant. The city timezone determines the local date, clock time and offset displayed to the reader. This prevents a New York forecast from being grouped according to midnight in Tbilisi or Berlin.

A timezone abbreviation alone can be ambiguous. The IANA database instead uses location-based identifiers and records offset changes. The database is updated when governments change civil-time rules, so software and operating systems also need current timezone data.

Daylight-saving transitions create unusual local days

Berlin and New York use seasonal clock changes under their current rules. Moscow and Tbilisi currently do not. When clocks move forward, a local calendar day can have 23 hours because one set of clock labels is skipped. When clocks move back, a day can have 25 hours because a local clock hour repeats with a different UTC offset.

A table that displayed only the local hour could make the repeated hour look like a duplicate. World Wide Weather News includes the timezone offset in its formatted hourly time, so the two occurrences remain distinguishable. Internally, validation requires consecutive hourly instants even when the visible local clock jumps or repeats.

The daily table groups those instants by the resulting local date. It must accept 23-hour and 25-hour days rather than forcing every date into a fixed 24-row shape. This is a correctness issue, not just a formatting detail: forcing UTC days onto local forecasts can move rain, wind or temperature values into the wrong date.

Today can be a partial forecast day

A snapshot retrieved in the afternoon no longer contains the morning as future forecast hours. If a provider-derived daily range is calculated from the remaining hourly samples, today’s low and high cover only the available part of the day. The page labels that basis and does not present the numbers as official full-day extrema.

Tomorrow is usually easier to compare because the available model horizon contains a full local day. Even then, the values remain forecast estimates that can change with the next model run. For a temperature record or a final daily observation, use an official observed-data source rather than this sampled forecast range.

How to compare cities correctly

To compare Berlin with New York at the same instant, use rows with the same underlying UTC timestamp even though their local clock labels differ. To compare each city at the same local clock time, accept that the rows represent different instants. Both comparisons can be useful, but they answer different questions.

This distinction also applies to publication timestamps. Articles use the editorial timezone for a consistent newsroom record. Forecast values use the city timezone because the reader needs to know when conditions are expected at that place.

What to check on the page

Every city page displays its IANA timezone near the heading and uses it in current, hourly, daily, source and update times. Near a daylight-saving transition, inspect the UTC offset shown with hourly rows. If an hour repeats, the offset tells you which occurrence the model value belongs to.

The approach keeps four concepts separate: the city’s timezone, the editorial timezone, the provider’s issue time and the forecast value’s valid instant. Keeping those concepts visible makes “today” a precise local date instead of an assumption based on the reader’s device.