DEV Community: Petrichor

Comparing weather across cities in Python: the timezone trap

Petrichor — Wed, 26 Aug 2026 08:32:59 +0000

Charting one city's forecast is a five-minute job. Charting four on the same axis raises a question single-city tutorials never ask: what does "the same time" mean across timezones?

This is a ~50-line Streamlit dashboard built on Meteosource's weather API, using its /point endpoint. Free tier, 400 calls a day, no card.

pip install streamlit pandas requests

The trap

Pull hourly forecasts for Prague and Reykjavík in local time, line them up in pandas, and Prague's 14:00 sits directly above Reykjavík's 14:00. Two moments two hours apart, drawn as though simultaneous. Every comparison you make from that chart is wrong.

Two defensible answers, and you have to pick one on purpose:

Absolute time. Request everything in UTC. "Right now, Barcelona is 17° warmer than Reykjavík." Correct for anything synchronised: flights, grid load, a live ops dashboard.
Local time. Request each city in its own zone, index by hour-of-day. "Barcelona's afternoon peak is 17° above Reykjavík's." Correct for comparing daily rhythms.

This one uses UTC, and you have to ask for it. Leave timezone out and the API gives you each point's own local time, which means the default is the trap. That's also why Meteosource's own Python wrapper, pymeteosource, always requests UTC internally and converts afterwards: same problem, same conclusion.

The app

import streamlit as st
import pandas as pd
import requests

API_KEY = st.secrets["METEOSOURCE_KEY"]
BASE_URL = "https://www.meteosource.com/api/v1/free/point"

CITIES = {
    "Prague": (50.0755, 14.4378),
    "Barcelona": (41.3874, 2.1686),
    "Reykjavík": (64.1466, -21.9426),
    "Athens": (37.9838, 23.7275),
}

st.title("🌍 City temperature comparison")

chosen = st.multiselect("Cities", list(CITIES),
                        default=["Prague", "Barcelona", "Reykjavík"])


@st.cache_data(ttl=1800)
def fetch(city):
    lat, lon = CITIES[city]
    # timezone=UTC is not the default, so it has to be explicit
    params = {"lat": lat, "lon": lon, "sections": "hourly",
              "timezone": "UTC", "units": "metric", "key": API_KEY}
    response = requests.get(BASE_URL, params=params, timeout=10)
    response.raise_for_status()
    rows = response.json().get("hourly", {}).get("data", [])
    if not rows:
        return None
    df = pd.DataFrame(rows)[["date", "temperature"]]
    df["date"] = pd.to_datetime(df["date"])
    df = df.set_index("date")
    return df.rename(columns={"temperature": city})


if chosen and st.button("Compare"):
    frames = []
    for city in chosen:
        try:
            frame = fetch(city)
        except requests.exceptions.RequestException as exc:
            st.error(f"{city}: {exc}")
            continue
        if frame is None:
            st.warning(f"{city}: no hourly data returned")
            continue
        frames.append(frame)

    if not frames:
        st.stop()

    wide = pd.concat(frames, axis=1)

    cols = st.columns(len(wide.columns))
    for col, city in zip(cols, wide.columns):
        col.metric(city, f"{wide[city].max():.0f} °C",
                   f"{wide[city].min():.0f} °C low", delta_color="off")

    st.line_chart(wide)
    st.caption("Hourly temperature in °C. All timestamps UTC.")

Put your key in .streamlit/secrets.toml as METEOSOURCE_KEY = "...", then streamlit run app.py.

Layout illustration with sample values. The free tier returns one day of hourly forecast, so your own chart will be shorter.

Two things worth noting

The endpoint takes one point at a time, so fetch() returns a one-column frame named after the city and pd.concat(frames, axis=1) joins them on the shared UTC index. Add a tenth city and nothing else changes.

@st.cache_data(ttl=1800) matters more than it looks. Streamlit reruns the whole script on every widget interaction, so without it, ticking a checkbox costs one request per selected city and a few minutes of fiddling eats the daily quota.

Where to go next

Precipitation lives at precipitation.total, nested, so it needs pd.json_normalize.
Local-time alignment: pass each city its own timezone and index on hour-of-day. Watch out for the day DST ends, when local time repeats an hour and you get two records with the same timestamp. Drop the duplicate with df[~df.index.duplicated(keep="first")] or pd.concat will fail.
place_id instead of coordinates: resolve names via /find_places_prefix. For mountains it gets you the peak's real elevation, where raw coordinates can land you lower down.
Don't index by position. The docs are explicit that sections and variables can grow over time.

If your cities seem to disagree about when the sun comes up, it's the timezone. It's always the timezone.

What a weather API comparison table leaves out

Petrichor — Mon, 17 Aug 2026 13:36:14 +0000

A comparison table gets a provider onto your shortlist. Something else gets it picked.

I answer the support inbox at Meteosource, a weather API, so I read most messages from people in the middle of an evaluation. Price comes up early in almost all of them. It is the easiest thing to compare, so it gets compared first.

It is rarely what settles it. Four other questions show up more often, and none of them are answered on a pricing page.

Can I test this in the next five minutes

Not features. Not accuracy. Whether a response can be on screen while the idea is still interesting.

A card form on a free tier loses at this step. So does a sales call before an API key. So does a signup flow asking for company size and use case before it gives you anything.

The message underneath all of it is the same one that kept landing in our inbox: I just want to see the JSON. That is why our free tier is 400 calls a day with no card, and it is the single change that moved trial signups the most.

What does the license actually allow

Plenty of free and cheap weather tiers are non commercial. Fine for a dashboard on your own wall. Not fine the moment your app has a paying user.

Anyone caught by this once now reads the terms before the docs. It takes two minutes and it saves a migration later. Worth checking on any provider you shortlist, including us.

What happens when I hit the limit

Three common answers, and they are not equally pleasant.

A hard 429 tells you immediately. Silent throttling gives you degraded data and no signal, which is the worst version because your users find out before you do. Overage billing gives you a surprise invoice after a retry loop runs over a weekend.

Predictable beats generous. A smaller cap you understand is easier to build on than a large one with fuzzy rules.

Will this pricing still work in a year

The pattern people are checking for is the cliff. A cheap starter plan, then nothing until an enterprise contract with a sales process attached.

If usage doubles, does the bill roughly double, or does it jump by a factor of ten. Anyone who has migrated off a provider mid project looks for that gap before writing a line of code.

We tried to avoid it by splitting features and call volume into separate choices, and by metering historical data per day per location instead of gating it behind a tier. It is not perfect. Our per location Renewables pricing genuinely does not suit anyone who wants to query a hundred scattered points occasionally, and a call based provider will be cheaper for that shape of usage. Different models fit different problems and pretending otherwise wastes everyone's time.

Why none of this shows up in a comparison table

Because none of it is comparable. Signup friction, license scope, limit behaviour and pricing shape are all specific to how you plan to use the thing. There is no column for them.

So they get left out, the table fills up with price and call counts, and the four questions that decide it end up as your own ten minutes of digging through docs and terms.

That cuts both ways. As a provider you cannot write your way out of any of it. They are product and terms of service decisions, sitting in public, and the only way to look better on them is to be better on them.

For anyone who has integrated a data API recently: what made you close the tab? Not the thing you complained about six months in, the thing that ruled a provider out on day one.

Finding the right price for a weather API

Petrichor — Wed, 05 Aug 2026 12:23:04 +0000

Why pricing a digital product is harder than it looks

Pricing a digital product is a strange kind of problem. There's no shelf to stock, and the cost of serving each customer isn't fixed. It grows with how much they use it. Usage is unpredictable, value is hard to see upfront, and a weather forecast can feel like a commodity, something buyers assume is all the same and shop for on price alone, even when the accuracy behind it isn't (in our case, 40 models blended with machine learning).

Price it too high, and it's out of reach for a hobby developer building something small. Price it too low, and it can't support what a business running thousands of locations actually needs. We ran into this from three different angles at Meteosource, and changed our pricing to deal with each one.

Challenge 1: usage is all over the place

A subscription API was always our way of letting a solo developer and a global operations team build on the same forecasts. But a fixed call limit doesn't work for both. One project makes 5,000 calls a day, another makes 500,000. Same plan, wildly different needs.

So to solve this, we split the offer into subscription levels, from Startup to Standard, and gave each level its own tier of call volumes. It works a bit like a table: pick your subscription for the features you need, then pick the call volume that matches how much you actually use, and find where you sit best. The details are on our pricing page, but the short version is: a side project and a scaling product don't have to fit in the same box anymore, and moving up as you grow is a lot more incremental.

Challenge 2: historical data doesn't fit neatly into a tier

Twenty years of historical weather data is one of the most valuable things we offer, and one of the hardest to price fairly. Bundle it into a plan, and people download the archive once and leave. Put it behind its own tier, and the price climbs until only the biggest customers can justify it. Neither worked.

We made it a metered add-on instead: $0.005 per day, per location, covering 20 years back, on any plan. You pay for exactly what you pull. A small project can dip into the archive without upgrading to an expensive tier, and the cost scales with actual usage instead of a flat guess.

Challenge 3: no tier existed for renewables forecasting

We kept hearing from people forecasting energy production (solar and wind) who needed something none of our existing plans covered: power-production forecasts per location, at hourly or 15-minute resolution.

So we built a Renewables tier from $19/location, covering PV systems and wind farms. It works whether you're modeling a few rooftop panels or a full farm. Past 20 sites, we set up custom pricing directly.

What stayed the same

Free is still 400 calls/day, no credit card, just an email. Enterprise is still fully custom, with parameters, data volume, SLAs, and applied-AI models built around the use case. Existing subscribers keep their current plan. We kept what was working, and moved around what needed a change.

We'll keep adjusting further if the need appears, and of course keep adding features to cover more of what people actually need. That's really the goal behind all of it.

But we're happy we cracked the logic of it, and it seems to be working well. What do you think about this change? What's your experience with the prices? Share it with us.