Sun and Moon Skill

Sunset time drives photo shoots, hikes, drone flights, fasting schedules, and the eternal "do we have time before dark" — and two keyless services answer it for any coordinates and date. This skill fetches, then does the two things the raw response doesn't: converts UTC to the place's local time (the classic wrong-answer generator in this domain), and derives the windows people actually want — golden hour, blue hour, usable daylight.

What This Skill Produces

• The times — sunrise, sunset, solar noon, twilight bounds — in the location's local time, labeled
• The derived windows — golden hour (~the hour after sunrise / before sunset), blue hour, day length and its current trend
• Moon phase — tonight's phase with the plain-language name
• The command — exact curl, rerunnable

Required Inputs

Ask for these if not provided:

• Location — lat/lon or a place name (geocode via https://geocoding-api.open-meteo.com/v1/search?name=Lisbon&count=1)
• The date — today default; any date works (both services take past and future dates)
• The real question — a shoot wants golden hour, a hike wants last-light, "is it a full moon" wants the phase — lead with theirs

Framework: The Calls and the UTC Trap

1. sunrise-sunset.org — primary: curl -s "https://api.sunrise-sunset.org/json?lat=35.68&lng=139.69&formatted=0&date=2026-07-19" → ISO times including civil_twilight_begin/end and day_length (seconds). Always formatted=0 and always convert: the times are UTC, and serving Tokyo's sunset as "09:57" is this domain's signature failure. Get the zone from the world-clock pattern or Open-Meteo's timezone=auto.
2. Open-Meteo — fallback and bulk: curl -s "https://api.open-meteo.com/v1/forecast?latitude=35.68&longitude=139.69&daily=sunrise,sunset,daylight_duration&timezone=auto&forecast_days=7" — timezone=auto returns times directly (safer), and a week in one call for trend questions.