Behind the Build: SR Weather – AI That Knows What Time It Is

I built a weather app where the AI actually knows what time it is in your location - not my server's time zone.

That sounds trivial. It wasn't.

The Problem

Every weather app shows temperatures and conditions. But when I asked existing AI assistants "what should I do today?", they'd suggest beach activities at 11 PM or morning jogs at midnight.

The AI knew the weather. It didn't know the time.

I wanted suggestions that actually made sense: dinner spots in the evening, breakfast cafés in the morning, cozy indoor activities at night.

The First Mistake

My initial implementation was straightforward:

const currentHour = new Date().getHours();

Worked perfectly in Sydney. Completely broken for users in London, New York, or Tokyo.

The problem? new Date() returns my server's local time, not the user's location time. A user checking Delhi weather at 9 PM local would get suggestions for 2:30 AM (Sydney time).

The Fix: Location-Aware Time

I needed to compute the local time at the weather location, not the device location:

The weather API returns a timezone identifier (like Asia/Kolkata or America/New_York). I used that to compute what time it actually is there:

const locationTime = new Date(
  new Date().toLocaleString("en-US", {
    timeZone: weather.location.timezone,
  })
);
const currentHour = locationTime.getHours();

Now when you search for weather in Tokyo, the AI knows it's evening in Tokyo - even if you're browsing from Sydney at a completely different hour.

Time-Aware Prompts

With accurate local time, I designed three AI insight types:

Summary: "It's 9 PM evening with 18°C and partly cloudy. Perfect evening to stay cozy indoors or enjoy the nightlife!"

What to Wear: "For 18°C evening: Evening smart casual - sweater, jeans, jacket, good shoes."

Activities: "EVENING (21:00): Cozy restaurant dinner, evening movie theater, night café with friends."

Each prompt explicitly tells the AI what time of day it is and what activities are appropriate:

CRITICAL: IT IS EVENING

🌆 EVENING: Suggest dinner restaurants, sunset viewing,
evening strolls, happy hour spots.

The CRITICAL emphasis matters. Without it, the AI would sometimes ignore the time context and suggest generic activities.

Protecting the API

Google's Gemini API isn't free at scale. I needed to prevent abuse without requiring user accounts.

Local Development: Direct API calls with optional key verification for testing the protection flow.

Production: All requests go through a Vercel serverless function. The Gemini API key lives only on the server. Users provide an access key that gets verified server-side before any AI call happens.

// Server-side verification
if (ACCESS_KEY && userAccessKey !== ACCESS_KEY) {
  return res.status(401).json({ error: "Invalid access key" });
}

This pattern - access keys via serverless functions - appears in several of my projects. It's simple, secure, and doesn't require databases or user management.

The Fallback System

AI APIs fail. Rate limits hit. Networks drop.

Every insight type has a handcrafted fallback that's still time-aware:

isNight
  ? "Perfect evening to stay cozy indoors or enjoy the nightlife! 🌙"
  : isMorning
  ? "Great start to the day! Morning freshness in the air. ☀️"
  : isAfternoon
  ? "Afternoon vibes - enjoy the rest of your day! 🌤️"
  : "Beautiful evening ahead! Time to unwind. 🌆";

Users get useful suggestions even when Gemini is unavailable. They might not notice the difference.

What I Learned

Time zones are hard. I spent more time debugging time calculations than any other feature. toLocaleString with explicit timezone is the cleanest solution.

Context makes AI useful. Generic AI responses are boring. Time-specific, temperature-specific, weather-specific responses feel genuinely helpful.

Serverless functions solve API protection. No need for complex auth systems. A simple access key verified on the server prevents unauthorized API usage.

What I'd Do Differently

I'd add forecast-aware suggestions. Currently, the AI only sees current conditions. "It's sunny now, but rain is coming at 3 PM - bring an umbrella to lunch."

I'd also implement rate limiting per access key rather than just key validation.

Try It

• Live Demo: weather.sreekarreddy.com
• Project Details: /portfolio/projects/sr-weather
• GitHub: View Source