The tp Parameter Does More Than You Think
When you call the World Weather Online Premium API, the tp parameter controls the time interval of hourly data returned inside each daily block. The options are 1, 3, 6, 12, or 24 — representing hours. Most tutorials default to tp=24 because it returns one row per day and the response stays small. That’s fine for a simple dashboard. It becomes a problem the moment you need to answer anything more specific than “what’s the weather like today.”
This post is about knowing when to move away from tp=24, what you actually get when you do, and where the real gotchas are.
What the Response Structure Actually Looks Like
The daily forecast response wraps hourly data inside each weather object under a key called hourly. At tp=24, that array has exactly one element. At tp=1, it has 24. The outer date-level fields — maxtempC, mintempC, uvIndex — stay the same regardless. They’re always day-level aggregates.
So if you’re pulling tp=24 and grabbing hourly[0]["chanceofrain"], you’re getting a representative value for that day — not the worst-case hour, not the morning, not the evening rush. For a lot of applications that’s totally acceptable. For anything operationally sensitive — a logistics platform routing vehicles, or a marina app advising on afternoon departure windows — you need the full profile.
The Anatomy of a tp=3 Response
Here’s what a single day’s hourly array looks like at tp=3 (eight entries, one per 3-hour slot):
"hourly": [
{ "time": "0", "tempC": "14", "windspeedMiles": "8", "chanceofrain": "10" },
{ "time": "300", "tempC": "13", "windspeedMiles": "7", "chanceofrain": "5" },
{ "time": "600", "tempC": "15", "windspeedMiles": "9", "chanceofrain": "8" },
{ "time": "900", "tempC": "18", "windspeedMiles": "12", "chanceofrain": "20" },
{ "time": "1200","tempC": "21", "windspeedMiles": "15", "chanceofrain": "45" },
{ "time": "1500","tempC": "20", "windspeedMiles": "14", "chanceofrain": "60" },
{ "time": "1800","tempC": "17", "windspeedMiles": "10", "chanceofrain": "30" },
{ "time": "2100","tempC": "15", "windspeedMiles": "8", "chanceofrain": "15" }
]At tp=24, you’d have gotten one row — probably interpolated around midday. You’d never see that 60% rain spike at 15:00. The application built on tp=24 tells the user it might rain. The application built on tp=3 tells the user it’s probably fine until early afternoon, then iffy.
That’s a different product.
When tp=1 Is the Right Call
Genuinely not that often. The response is six times larger than tp=6 and 24 times larger than tp=24. If you’re calling 5-day forecasts for multiple cities in a single user session, the payload sizes add up fast. More importantly, the underlying forecast model doesn’t have independent data at every single hour — there’s interpolation happening between model run timesteps. The practical difference between tp=1 and tp=3 is often smaller than you’d expect.
Use tp=1 when:
- You’re building a heatmap or chart that benefits from smooth hourly curves (feels-like temperature over the day, solar radiation estimates)
- You need to detect within-hour crossings of a threshold — for example, the exact modelled hour when wind exceeds a permit limit at a construction site
- You’re storing the response in a time-series database and want consistently spaced 1-hour rows without doing client-side interpolation yourself
For marine data, tp=3 is usually enough. Wave height and swell period don’t change dramatically hour-to-hour across most forecast windows, and at tp=1 you’re largely getting interpolated values between the 3-hourly model outputs anyway.
The API Call Costs Angle
On the free tier — 500 calls per day, no credit card — the tp setting doesn’t change how many API calls you consume per request. One call is one call regardless of whether you get 5 rows or 120 rows back. But it absolutely affects downstream processing: parsing, storage, and if you’re piping this into any kind of LLM context (we publish a WWO MCP server that lets tools like Claude and Cursor call our API directly), token count scales linearly with response size.
If you’re on the free tier and building something exploratory, tp=6 is probably the sweet spot — small enough to parse quickly in a script, granular enough to see morning/afternoon/evening variation.
Historical Data: Same Parameter, Different Implication
The tp parameter works the same way against the historical endpoint — our archive goes back to July 2008 for standard weather and January 2015 for marine. The tradeoff shifts here, though. When you’re pulling a week of historical data to train a model or do anomaly detection, tp=1 becomes more attractive because you’re not making latency-sensitive calls. You make a batch request, store the result, and never call again for those dates.
One catch worth knowing: historical hourly data has gaps in the early years. Pre-2010 in particular, some parameters that exist cleanly at tp=1 in recent data come back null or estimated for stations with sparse historical observations. Check your null rates before assuming the 2008–2012 archive has the same density as 2020+. It doesn’t, uniformly.
A Concrete Integration Pattern
If you’re building a feature that shows both a daily summary and a detailed hourly breakdown on demand, don’t make two separate API calls. Make one call at tp=3 and derive the daily summary client-side:
import requests
def get_forecast(location, api_key, days=5):
params = {
"key": api_key,
"q": location,
"format": "json",
"num_of_days": days,
"tp": 3, # 8 slots per day — enough for daily + hourly views
"cc": "yes",
"includelocation": "yes"
}
r = requests.get(
"https://api.worldweatheronline.com/premium/v1/weather.ashx",
params=params,
timeout=10
)
r.raise_for_status()
return r.json()["data"]
def daily_summary(day):
"""Derive daily summary from 3-hourly slots."""
slots = day["hourly"]
return {
"date": day["date"],
"max_c": day["maxtempC"], # already computed by API
"min_c": day["mintempC"],
"peak_wind": max(int(s["windspeedMiles"]) for s in slots),
"max_rain": max(int(s.get("chanceofrain", 0)) for s in slots),
"desc": slots[4]["weatherDesc"][0]["value"] # midday slot
}
data = get_forecast("Edinburgh", "YOUR_API_KEY")
for day in data["weather"]:
summary = daily_summary(day)
print(f"{summary['date']} max rain chance: {summary['max_rain']}% peak wind: {summary['peak_wind']} mph")
The peak_wind line is worth pausing on. At tp=24, you get whatever wind speed the API returns for its single representative slot — typically a daytime value. Deriving the peak yourself from 8 slots can surface significantly higher gusts that would otherwise be invisible. For a sailing or hiking use case, that matters.
One Genuine Limitation to Know
The tp parameter only affects the hourly array inside the response. It has no effect on current_condition (always a single real-time snapshot) and no effect on date-level aggregate fields. If you’re only reading maxtempC and mintempC, tp is completely irrelevant to your output — but you’re still paying the response-size cost of the larger hourly array whether you read it or not. If you genuinely only need daily aggregates, set tp=24 and keep your payloads clean.
Choosing Your Interval
Ask what the narrowest decision window is for your user. A traveller picking which day to visit a city? tp=24. A sailor deciding whether to leave port before or after lunch? tp=3. An energy platform modelling solar output against cloud cover through the day? tp=1.
The parameter is one line. Defaulting to 24 without thinking about it tends to stay invisible right up until a user files a support ticket asking why your app didn’t warn them about the afternoon storm — and you realise the data was there all along, just averaged away.
The post Hourly vs. Daily Intervals: Picking the Right tp Parameter appeared first on Weather Blog.
