How are weather metrics calculated over various time periods in different weather queries?

How Weather Metrics Are Calculated Over Different Time Periods

Weather data can represent either a condition at a particular time or a value calculated over a period of time.

Understanding that distinction is important when interpreting daily, hourly, and sub-hourly weather records.

For example:

  • Temperature describes the atmospheric state at a time or can be summarized over a period.
  • Maximum temperature is calculated over an interval.
  • Precipitation is accumulated over an interval.
  • Humidity can represent a value at a time or an average over a longer period.
  • Wind gust represents the strongest gust during a period.
  • Snowfall represents accumulation during a period.

The Visual Crossing Timeline Weather API handles these differences automatically and returns values appropriate to the time resolution being requested.

For the complete API reference, see the Timeline Weather API documentation.

Point-in-time values and period values

Weather elements generally fall into two broad categories.

State or point-in-time values

Some weather elements describe the atmospheric state at or near a particular time.

Examples include:

temp
feelslike
humidity
dew
pressure
cloudcover
visibility
winddir

In an hourly or sub-hourly record, these values generally describe conditions associated with that record’s time.

For example:

2026-08-21T14:00:00
temp = 82.4
humidity = 54

describes the temperature and humidity associated with the 2:00 PM record.

Period or accumulated values

Other weather elements only make sense when measured over an interval.

Examples include:

precip
snow
solarenergy
precipcover

These describe what happened during the period represented by the record.

For example:

precip = 0.18

on an hourly record means precipitation associated with that hourly period, not precipitation at a single mathematical instant.

Daily weather records

A daily Timeline record summarizes a local calendar day for the requested location.

For example:

{
  "datetime": "2026-08-21",
  "tempmax": 86.2,
  "tempmin": 65.4,
  "temp": 75.1,
  "precip": 0.42,
  "humidity": 63.7,
  "windspeed": 14.8,
  "windgust": 27.3
}

The values represent different types of aggregation over that day.

Typical examples include:

FieldDaily interpretation
tempmaxMaximum temperature during the day
tempminMinimum temperature during the day
tempRepresentative or average temperature for the day
precipTotal precipitation during the day
snowTotal new snowfall during the day
humidityRepresentative or average humidity during the day
windspeedRepresentative wind speed for the day
windgustMaximum gust during the day
solarenergyTotal solar energy during the day

Not every weather element uses the same aggregation rule.

A field should therefore be interpreted according to its definition rather than assuming that every daily value is simply an arithmetic average of the hourly values.

For current field definitions, see the Weather Data Documentation.

Daily records use the location’s local calendar day

Timeline formatted dates and times are normally based on the timezone of the requested location.

For example, a daily record for:

2026-08-21

represents August 21 in the local timezone of that location.

This matters when comparing weather data across locations in different timezones.

A calendar day in London and a calendar day in New York do not cover exactly the same UTC period.

The Timeline response includes timezone information such as:

timezone
tzoffset

For more information, see Dates and Times in the Weather API.

Daylight saving time can change the length of a local day

A local calendar day is not always exactly 24 hours.

During daylight saving time transitions, a day can contain:

  • 23 hours when clocks move forward
  • 25 hours when clocks move backward

This affects the number of hourly records that can appear within the day.

For example, when a repeated local hour occurs during the autumn transition, two records can have the same formatted local clock time but different:

datetimeEpoch

values.

When unambiguous time handling is important, use datetimeEpoch.

For more information, see How to Handle Daylight Saving Time in the Weather API.

Hourly weather records

Hourly records provide conditions at a much finer time resolution.

For example:

{
  "datetime": "14:00:00",
  "temp": 82.4,
  "humidity": 54.0,
  "precip": 0.08,
  "windspeed": 11.2,
  "conditions": "Rain"
}

Some hourly fields describe the conditions associated with that hour, while others represent an amount or extreme over the hourly interval.

For example:

  • temp describes the temperature associated with the hourly record.
  • humidity describes humidity associated with that record.
  • precip represents precipitation accumulated for the hourly period.
  • windgust can represent the strongest gust associated with the period.
  • solarenergy represents energy accumulated during the period.

The exact meaning of each element is defined by the Weather Data documentation.

Do daily values always equal calculations made from the returned hourly records?

Not necessarily.

It can be tempting to assume that a daily value is always calculated directly from the hourly records returned in the same API response.

For example:

daily temp =
average(all returned hourly temp values)

or:

daily precip =
sum(all returned hourly precip values)

may often produce similar results, but applications should not assume they will always be exactly identical.

Daily and hourly weather can involve:

  • Different source availability
  • Different source-selection logic
  • Different interpolation or aggregation processes
  • Missing observations
  • Different native source resolutions
  • Rounding

For authoritative use, treat the daily record as the API’s daily value rather than recalculating it from the hourly records unless your application specifically requires its own aggregation method.

Historical hourly weather

For historical hourly records, Visual Crossing processes available observations to produce weather representative of the requested location and hour.

Available sources can include:

  • Weather stations
  • Airport observations
  • Mesonet stations
  • Radar
  • Satellite and other remote observations

Source availability can vary by element.

For example, one source may provide temperature while another source contributes precipitation information.

Historical values are therefore not necessarily a raw copy of one individual station record.

For remote-data details, see Using Remote Data Sources in the Weather API.

Historical daily weather

Historical daily records summarize the weather for each requested local calendar day.

For example:

/timeline/London,UK/2026-07-01/2026-07-07

with:

include=days

returns one daily record for each day.

The daily fields summarize the weather according to the definition of each weather element.

For example:

tempmax

is the day’s maximum temperature, while:

precip

is the day’s total precipitation.

Forecast hourly weather

Hourly forecast records describe the conditions expected during individual forecast hours.

Typical state variables include:

temp
feelslike
humidity
pressure
windspeed
winddir
cloudcover

while accumulated or period-based forecast values include fields such as:

precip
snow
solarenergy

Forecast source resolution varies by location, model, and forecast period.

The Timeline API provides the resulting forecast through a consistent hourly structure even though the underlying forecast sources may have different native resolutions.

Forecast daily weather

Daily forecast records summarize the forecast for the local calendar day.

For example:

{
  "datetime": "2026-08-22",
  "tempmax": 84.5,
  "tempmin": 66.1,
  "precip": 0.21,
  "precipprob": 55,
  "conditions": "Rain, Partially cloudy"
}

Typical daily forecast interpretations include:

tempmax → expected maximum temperature
tempmin → expected minimum temperature
precip → expected total precipitation
windgust → strongest expected gust
conditions → summarized conditions for the day

Precipitation requires a time interval

Precipitation is one of the most important examples of a period-based weather element.

An instantaneous precipitation amount is not generally meaningful in the same way as an instantaneous temperature.

The:

precip

field represents precipitation accumulated over the period associated with the record.

For a daily record, it represents daily precipitation.

For an hourly record, it represents precipitation for the hourly period.

For a sub-hourly record, it represents precipitation for the corresponding sub-hourly interval.

This distinction matters when combining or comparing precipitation values across different time resolutions.

Precipitation probability is different

The:

precipprob

field represents the forecast probability of measurable precipitation.

It is not an accumulated amount.

For example:

precip = 0.20
precipprob = 70

means that the forecast contains an expected precipitation amount of 0.20 in the selected units and a 70% probability of measurable precipitation for the applicable period.

Do not add precipitation probabilities together across multiple hours or days.

Snow and snow depth behave differently

The:

snow

field represents new snowfall during the period.

The:

snowdepth

field represents snow already on the ground.

Therefore:

snow = 0
snowdepth > 0

is normal.

It means no new snow fell during the period while previously accumulated snow remained on the ground.

Wind speed and wind gust are different types of values

Wind fields also illustrate why element definitions matter.

For example:

windspeed

represents the wind speed associated with the record or summarized period.

windgust

represents a peak gust value associated with the period.

For daily records, the gust is therefore not expected to behave like an arithmetic average.

Solar radiation and solar energy are different

Solar fields use different measurement concepts.

solarradiation

represents solar radiation intensity.

solarenergy

represents energy accumulated over a period.

The distinction is similar to the difference between a rate and a total.

When aggregating solar data yourself, make sure you understand whether the element represents an instantaneous or averaged intensity versus accumulated energy.

Sub-hourly records

Sub-hourly weather is requested with:

include=minutes

where supported.

Sub-hourly records follow the same general principle:

  • State elements describe conditions associated with the sub-hourly record.
  • Accumulated elements describe the corresponding sub-hourly period.

For more information, see Sub-Hourly Data in the Timeline Weather API.

Aggregating weather yourself

Sometimes an application needs to create its own aggregation.

For example, you may want:

  • Business-hour temperature rather than full-day temperature
  • Precipitation between 8 AM and 5 PM
  • Maximum wind gust during an event
  • Average temperature during a production shift
  • Weather statistics over a custom 6-hour window

In these cases, request the appropriate hourly or sub-hourly data and perform the required aggregation within your application.

For example, precipitation can be summed:

total precipitation =
sum(precip for selected records)

while temperature might be averaged:

average temperature =
mean(temp for selected records)

and wind gust might use:

maximum gust =
max(windgust for selected records)

The correct aggregation method depends on the weather element and the analytical question.

Be careful when averaging averages

One important statistical consideration is that averages over different periods should not always be averaged directly.

For example, suppose one period contains 24 hourly observations and another contains only 12 valid observations.

Simply calculating:

(day1_average + day2_average) / 2

weights both days equally, even though they may contain different numbers of observations.

If your analysis requires precise aggregation, use the underlying records and choose a weighting method appropriate to your application.

Example: daily historical weather

A request such as:

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/services/timeline/London,UK/2026-07-01/2026-07-07?unitGroup=metric&include=days&key=YOUR_API_KEY

returns one daily summary record for each requested day.

Typical interpretations are:

tempmax → maximum temperature during the day
tempmin → minimum temperature during the day
temp → representative daily temperature
precip → total daily precipitation
windgust → maximum gust during the day

Example: hourly historical weather

Changing the request to:

include=hours

returns hourly weather.

For example:

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/services/timeline/London,UK/2026-07-01?unitGroup=metric&include=hours&key=YOUR_API_KEY

Each hourly record contains values appropriate to that hourly period.

Which resolution should I use?

Choose the resolution based on the question you are trying to answer.

Use daily data when you need:

  • Daily maximum/minimum temperature
  • Daily precipitation
  • Long historical datasets
  • General climate or business analysis

Use hourly data when you need:

  • Timing of precipitation
  • Conditions during business hours
  • Transportation or event analysis
  • Temperature through the day
  • Hour-specific weather

Use sub-hourly data when:

  • Hourly resolution is insufficient
  • The application needs high-frequency weather
  • The available source resolution supports the requirement

Summary

Weather metrics are not all calculated in the same way.

Some elements describe conditions associated with a point or interval, while others represent totals, averages, minimums, maximums, or other summaries over a period.

The most important principles are:

  • Daily records summarize a local calendar day.
  • Hourly records provide weather at hourly resolution.
  • Sub-hourly records provide finer time resolution where available.
  • Temperature and similar state fields describe atmospheric conditions.
  • Precipitation and snowfall represent accumulated amounts over a period.
  • Maximum and minimum fields represent extremes over a period.
  • Daily values should not always be assumed to equal calculations performed on the returned hourly values.
  • Timezone and daylight-saving transitions affect how local calendar periods are represented.

For the exact definition of each weather element, see the Weather Data Documentation.

For complete request details, see the Timeline Weather API documentation.