PhotoPills costs $10.99 and has been in the top paid photography apps for years. The Photographer's Ephemeris charges $11.99. Photographers pay real money for apps that tell them when and where the light will be right.

The core of these apps is astronomical calculation: where is the sun, where is the moon, when is golden hour, when is the Milky Way visible. This is well-understood math—you can find the algorithms on Wikipedia—but implementing it correctly is tedious, and the edge cases (polar regions, atmospheric refraction, elevation adjustments) will bite you.

If you're building a photography planning app, a camera feature that suggests optimal shooting times, or any product where "light conditions" matter, you need this data. You can implement the calculations yourself, or you can use an API that's already done it.

Photographers don't think in terms of "solar elevation angles." They think in terms of light quality. The data requirements map to specific shooting scenarios:

The period when the sun is between 0° and 6° above the horizon. The light is warm (color temperature around 3000K), soft, and directional without being harsh. Portrait photographers love it. Landscape photographers plan entire trips around it. Wedding photographers schedule couples' sessions for it.

Golden hour happens twice a day—after sunrise and before sunset—and lasts roughly 30-60 minutes depending on latitude and season. Near the equator, it's short. In northern latitudes during summer, it can stretch longer. Your app needs to tell photographers exactly when it starts and ends for their specific location.

The period when the sun is between 4° and 6° below the horizon. The sky turns deep blue while there's still enough ambient light to see. City photographers love blue hour because artificial lights are on but the sky isn't black. The contrast between warm building lights and cool sky creates compelling images.

Blue hour is shorter than golden hour—typically 15-30 minutes. It's the window between "too bright" and "too dark," and photographers who want to capture it need precise timing.

Astrophotographers care about twilight more precisely:

• Civil twilight (sun 0-6° below horizon): Sky still bright, horizon visible. Not dark enough for stars.

• Nautical twilight (sun 6-12° below horizon): Horizon barely visible. Some bright stars appear.

• Astronomical twilight (sun 12-18° below horizon): Sky dark enough for most astronomy. Faint stars visible.

• Night (sun more than 18° below horizon): Full darkness. Milky Way visible in dark locations.

If someone's planning a Milky Way shot, they need to know when astronomical twilight ends—that's when the Galactic Center becomes visible. If they're doing star trails, they need to know how long until dawn.

The moon matters for two reasons: as a subject and as a light source.

As a subject, photographers want to shoot specific phases—full moon rises, crescent moons, lunar eclipses. They need to know when the moon rises and sets, and its phase on a given date.

As a light source, the moon affects night photography. A full moon washes out the Milky Way. A new moon means darker skies but no moonlight for foreground illumination. Photographers planning night shoots need to know the moon's illumination percentage.

For compositions where the sun or moon appears in a specific position relative to landscape features—rising behind a mountain, setting through an arch, illuminating a specific face of a building—photographers need to know the compass direction.

"The sun rises in the east" isn't precise enough. On the summer solstice in New York, the sun rises at about 57° (ENE). On the winter solstice, it's about 118° (ESE). The exact position matters for planning shots.

PhotoPills, The Photographer's Ephemeris, Sun Surveyor—these apps exist because photographers need this data presented in specific ways:

Location-specific precision. Not "sunrise in New York" but "sunrise at this exact GPS coordinate on this exact date." A photographer scouting a specific overlook needs the sun's position from that spot, not from the nearest city.

Visual planning. AR overlays showing where the sun will be. Maps with sun/moon paths. Timeline views of the day. The data needs to be presented in ways that support planning compositions.

Offline capability. Photographers work in remote locations without cell service. The calculations need to work offline once you have the location and date.

These apps have proven the market. Photographers will pay for tools that help them plan shots. The opportunity for other apps is integrating this capability where it makes sense—camera apps, travel apps, outdoor activity apps—without requiring users to switch to a dedicated ephemeris app.

If you decide to implement astronomical calculations yourself, here's what you're signing up for:

The basic math is public. NOAA publishes solar position algorithms. The equations for moon phase are well-documented. You can find implementations on GitHub. This isn't secret knowledge.

The edge cases are annoying. What happens when there is no sunrise? (Polar regions during winter.) What happens when there's no sunset? (Polar regions during summer.) What about the midnight sun, when golden hour technically never ends? Your code needs to handle these cases gracefully.

Atmospheric refraction. The sun appears to rise earlier and set later than the geometric calculation suggests because the atmosphere bends light. This adds roughly 2-4 minutes depending on conditions. If you're calculating golden hour to the minute, refraction matters.

Elevation adjustments. Sunrise is earlier when you're on a mountain than when you're at sea level. For photographers at elevation, this matters. Most basic calculators ignore it.

Time zones and DST. You're calculating positions in UTC and displaying times in local time. Getting this wrong means your app shows sunrise at the wrong time, which is worse than not showing it at all.

None of this is impossible. It's just work—work that's already been done by others, and work that's tangential to whatever your actual app does. If you're building a photography planning app, maybe you want to implement the astronomy yourself. If you're adding a "best time to shoot" feature to a camera app, you probably don't.

We built astronomical calculation into World Data API:

Sunrise and sunset. For any location and date, with times adjusted for atmospheric refraction. We return the actual observed sunrise/sunset, not just the geometric calculation.

Golden hour and blue hour. Start and end times for both morning and evening golden hour, and both twilight blue hours. The exact windows when the light is right.

Twilight phases. Civil, nautical, and astronomical twilight times. For astrophotographers who need to know when the sky is truly dark.

Moon phase and illumination. Current phase (new, waxing crescent, first quarter, etc.) and illumination percentage. Rise and set times for the moon.

Solar noon and day length. When the sun is highest, and total daylight hours. Useful for planning midday shoots where you want to avoid harsh light, or for travel apps showing how much daylight users will have.

We're providing calculation results, not a full ephemeris platform. There are things outside our scope:

Precise lunar altitude/azimuth over time. We provide moonrise, moonset, phase, and illumination. We don't provide continuous position tracking for the moon throughout the day. If you need "exactly where is the moon at 3:47 PM for my composition," you'll need more granular data than we provide.

Eclipse predictions. We don't provide solar or lunar eclipse data. For eclipse photography planning, you'll need a dedicated eclipse resource.

AR visualization. We provide the data. Overlaying it on camera views, showing sun paths on maps, building visual planning interfaces—that's your app's job.

Milky Way positioning. We provide moon illumination (which affects Milky Way visibility), but not Galactic Center rise/set times specifically.

Weather integration. We can tell you when golden hour is. We can't tell you if it'll be cloudy. Light quality predictions require weather data we don't have.

Local horizon data. Our calculations assume a flat horizon. If there's a mountain to the east, actual sunrise will be later than we calculate. Terrain-aware calculations require elevation data for the surrounding area, which we don't have.

Atmospheric refraction adjustments for specific locations. We use standard atmospheric correction. We don't adjust for specific temperature, pressure, or humidity conditions at your location.

We're providing the core astronomical calculations. A full-featured photography planning app would layer additional data (weather, terrain, location scouting) on top.

Astronomical calculations have known precision limits:

Atmospheric effects. Refraction varies with atmospheric conditions (temperature, pressure, humidity). We use standard atmospheric correction, which is accurate to within a couple of minutes for most conditions. In extreme conditions (very cold, very humid), actual times may differ slightly.

Elevation. We don't currently adjust for observer elevation. For photographers at high altitude, actual sunrise will be slightly earlier than we calculate. The difference is typically under 5 minutes even for significant elevation differences, but it exists.

Polar regions. During polar day/night, some of our calculations return special values indicating "no sunrise" or "no sunset." Apps using our data need to handle these cases.

For most photography planning use cases, our accuracy is sufficient. Photographers typically arrive early and stay late; knowing golden hour starts at 7:23 versus 7:25 rarely matters operationally. But if your use case requires sub-minute precision, be aware of these limitations.

You're building a photography planning app and don't want to implement astronomical calculations from scratch. Or you're adding a "best time to shoot" feature to a camera app. Or you're building a travel app where "when to see the sunset" is a reasonable feature. Or any product where light conditions matter and users would benefit from knowing optimal times.

You want the data without the implementation work, and you're okay with the accuracy limitations we've described.

The API is REST-based, returns JSON, and authenticates via the X-API-Key header.

Astronomy endpoints are premium and require a paid tier: Starter at $9/month (15,000 requests), Pro at $49/month (100,000 requests), Growth at $149/month (500,000 requests). Annual billing saves about 25%.

You can query by coordinates directly, or use location names that resolve to coordinates via our city or airport data:

curl "https://worlddataapi.com/v1/astronomy/sun?lat=36.2704&lon=-121.8081&date=2025-06-15" \
  -H "X-API-Key: YOUR_API_KEY"

Sign up at worlddataapi.com/dashboard to get an API key. Documentation is at worlddataapi.com/docs. We have guides for photography-related use cases:

• Building a Golden Hour Calculator

• Adding Sunrise and Sunset Times

• Building a Moon Phase Display