Internet Time and Local Weather for a Clock

• Confirmed location
• Weather data
• Clock

What you will learn

• Separate time synchronization from local-time presentation.
• Resolve and save a confirmed location.
• Design bounded weather requests with explicit stale-data handling.

Before you start

Read about the clock architecture and the Arduino loop; understand how to read JSON.

How does Internet time differ from a time zone?

SNTP uses a server response to set system time; the time zone determines its local representation. Espressif documents setting TZ, calling tzset() and then using localtime() for local time.

The proposed design stores and exchanges time in a standard reference and applies local rules when rendering. The weather API zone and firmware zone must refer to the same area. If a service returns an IANA time-zone name, use a checked mapping or restrict setup to supported regions. An IANA name should not be passed directly to an interface expecting a POSIX rule string.

Record successful synchronization. During an outage, continue reading the local clock. If startup has no valid time, show an unset indication and allow setup instead of presenting a default date as real time. The chip RTC timer resets on a power-on reset, so surviving complete power removal requires separate backup hardware.

For alarms, the proposed design stores a local scheduled time and repeat days, then computes the next occurrence under the current time zone. Continue checking it offline while time remains valid. After power loss without valid time, show “Set time first”; allow button entry of date, time and zone before arming the schedule.

Recompute the next occurrence after synchronization or a zone change while retaining the handled-occurrence key. The initial policy skips an occurrence crossed by a forward adjustment. Backward corrections and repeated local times must not ring the same occurrence twice. Snooze uses a separate elapsed-time counter so calendar corrections do not extend its wait. The firmware article explains schedule storage and alarm states.

• Synchronized time
• Time-zone rules
• Displayed local time

How should the clock obtain its location?

For a stationary clock, the proposed first version selects a place rather than adding GPS. The geocoding API takes a search term and returns matching locations, including names, coordinates and time-zone information.

The proposed setup asks for a place name, shows results with administrative areas and saves a confirmed selection. Confirmation matters when places share a name. Store the name for display and coordinates for weather requests. If search fails, allow a revised query or coordinate entry in advanced settings.

Arduino-ESP32 Preferences uses storage retained across restarts and power loss. This design uses it for the confirmed place. Changing location increments a selection version; accept weather only for the current version. A slow response from a previous request then cannot overwrite the new location's weather.

A later automatic-location feature can add a user-authorized coordinate source while retaining manual entry. The manual place-entry example does not need automatic relocation.

• Matching places
• User confirmation
• Saved settings

How can weather updates leave the interface usable?

Request only the information the face needs and replace its data snapshot only after validating a response. Open-Meteo accepts coordinates and weather variables and returns JSON. Its current conditions are based on weather-model data, rather than a sensor inside the clock's room.

The proposed sequence makes an HTTPS request with a deadline, checks the response, parses required fields and verifies completeness. Check types, units and missing values. Missing temperature gets an unavailable indication; zero is not a substitute for missing data.

Keep the source's validity time separate from the reception time. The design can use the last successful download to track operational freshness, while retaining the source timestamp. Room temperature requires its own sensor input and label.

Check service terms during prototyping. Open-Meteo restricts the free API to non-commercial use; commercial distribution requires an appropriate arrangement. Provide the attribution required by the service in a suitable display or information page before release.

• Network response
• Validate data and location
• Accept update
• Retain with age indication

Real-world example

A user moves the clock and selects a new place while an old weather request is pending. The firmware saves the new selection, discards the old response when it arrives and requests data for the confirmed coordinates.

If that request fails, the face reports that weather for the new place is unavailable. It must not show the previous location's temperature under the new name. Time continues using the current time configuration.

Common misunderstandings

Network time automatically means correct local time. Synchronization and time-zone configuration are separate requirements.

Weather temperature is room temperature. Weather-model output and an indoor sensor reading come from different sources.

Frequently asked questions

Should every weather request repeat the place search?

This design searches again only when the user changes location. Later weather requests reuse stored coordinates.

Should an outage erase the forecast?

Data for the same location can remain with a stale indication. Data for a previous location must remain separate from the new selection.

Is the free API suitable for clocks sold commercially?

Check the terms and select an appropriate plan. Non-commercial access does not automatically cover a product sold to customers.