Golden Hour Calculator

Golden hour, blue hour, sunrise, solar noon and sunset for a list of cities or your own coordinates, plus a seven-day planning table in local time.

🌐 Español

All times are local to London, UK — Europe/London (UTC+01:00) — not your device's own clock (UTC).

Sun, Aug 30, 2026

Morning blue hour05:34 – 05:48
Morning golden hour05:48 – 06:54
Sunrise06:09
Solar noon13:01
Sunset19:51
Evening golden hour19:06 – 20:12
Evening blue hour20:12 – 20:26
Day length13h 42m

Week ahead

DateMorning goldenSunriseSunsetEvening golden
Sun, Aug 3005:48 – 06:5406:0919:5119:06 – 20:12
Mon, Aug 3105:50 – 06:5606:1119:4919:04 – 20:10
Tue, Sep 105:51 – 06:5706:1219:4619:02 – 20:08
Wed, Sep 205:53 – 06:5906:1419:4419:00 – 20:05
Thu, Sep 305:55 – 07:0006:1619:4218:58 – 20:03
Fri, Sep 405:56 – 07:0206:1719:4018:55 – 20:01
Sat, Sep 505:58 – 07:0306:1919:3818:53 – 19:58

Golden hour is shown for sun altitudes between -4° and +6°, blue hour between -6° and -4° — the convention photography planning tools use. Computed locally with the NOAA solar-position algorithm; nothing is sent to any server.

🔒 Private by design: everything runs locally in your browser and never uploaded to any server.

Altitude bands, not a fixed sixty minutes

Golden hour is not a duration, it is a range of sun angles. This page uses the convention photography planning apps settled on: golden hour is every moment the sun’s centre sits between 4° below the horizon and 6° above it, and blue hour is the band from 6° below to 4° below. The sunrise and sunset rows use a separate altitude, 0.833° below the geometric horizon, which is the standard allowance for atmospheric refraction plus the sun’s own visible radius.

Because those are angles, the length of the window depends entirely on how steeply the sun climbs where you are standing. On 21 June 2026 the evening golden window runs about 83 minutes in London and about 44 minutes in Singapore, where the sun drops almost vertically. New York on 21 March 2026 falls between the two at about 53 minutes. The word “hour” is a rough average of a quantity that ranges from well under an hour to, at high latitude in summer, the entire night.

Everything is solved with the NOAA solar-position equations written out in plain JavaScript: Julian day, solar declination, the equation of time, and then the hour angle at which the sun reaches each altitude. Each event time is refined twice, re-evaluating declination and the equation of time at the candidate instant, because both drift enough within a single day to move a solstice sunrise by up to a minute. The project’s tests pin every scenario from 69.6°N to 33.9°S against an independent reference within two minutes.

Picking a place and a day

There is no calculate button. The whole widget recomputes as you change either control.

  1. Choose a city from the Location menu. It opens on London.
  2. Set Date using the date field, which starts on today and accepts any past or future day.
  3. Read the day card, which lists Morning blue hour, Morning golden hour, Sunrise, Solar noon, Sunset, Evening golden hour, Evening blue hour and Day length.
  4. Optionally press 📍 Use my location to swap the city for your browser’s coordinates. A new “My location (from browser)” entry then appears at the top of the location menu.
  5. Scroll the Week ahead table for seven consecutive days starting at the date you chose.

Two things about that table are worth noting before you plan around it. Its columns are Date, Morning golden, Sunrise, Sunset and Evening golden, so blue hour appears only in the day card above it, not in the week view. And the week always starts on your chosen date rather than on a Monday, which is what you want when you are counting forward from a travel day rather than reading a calendar.

Sydney times while you sit in Madrid

The classic way a sunrise table goes wrong is to compute a distant city’s sunrise correctly and then print it in the visitor’s own time zone. Every event here is computed as a genuine UTC instant and converted for display using the city’s own IANA zone, which is stored alongside its coordinates. A note under the controls names that zone and its offset for the day being shown, and when it differs from your device’s zone it says so outright.

The conversion machinery is not written twice. It is imported from the Time Zone Converter, which already had its Intl-based zone handling verified against real daylight saving transitions, and the calendar arithmetic that walks the week forward comes from Days Between Dates rather than from fresh month-length code. Reusing two already-tested modules is the reason this page has no date rollover bugs of its own to talk about.

The one case where the visitor’s own zone is used is the geolocation path, and there it is the correct answer: if the coordinates are where you physically are, your browser’s zone is that location’s zone.

The week London puts its clocks back, row by row

Set the location to London and the date to 22 October 2026 and the table shows the transition happening. Sunrise reads 07:36, 07:38 and 07:39 across Thursday to Saturday, then Sunday 25 October drops to 06:41. The single zone note under the controls follows the date you picked, so it reads UTC+01:00 here; set the date to 25 October and it becomes UTC+00:00. Sunset moves from 17:48 to 16:46 across the same boundary, and the evening golden window slides with it, from 17:01 to 18:09 on the Saturday to 15:58 to 17:07 on the Sunday.

Nothing in the solar mathematics changed overnight. The sun kept moving by about two minutes a day; only the labels attached to those instants jumped by an hour, because the browser’s zone database applied the change on the correct date. Being able to watch that in one seven-row table is a decent proof that the display layer is doing its job.

A sunset that lands after midnight reads as an early-morning time

Ask ReykjavĂ­k for 21 June 2026 and the day card looks briefly broken: sunrise 02:55, sunset 00:04. The sunset instant genuinely falls a few minutes into the next morning, and the cells print a clock time with no date attached, so it reads as an earlier time than its own sunrise.

The Day length row is what disambiguates it. It reads 21h 09m, which is only consistent with a sunset that belongs to the following day. If you are reading these numbers late at night before a shoot, that row is the one to sanity-check against. It is also worth remembering that the calculated horizon is a mathematical one. A ridge line, a terrace of houses or a bank of cloud will move your usable light by more than any algorithm’s error bar, which is why scouting the spot still matters more than the table does. If you want to know what a past shot’s light looked like at a given hour, the EXIF Viewer reads the capture timestamp back out of the photo, and you can set this page to that date to see the same window.

Midnight sun, polar night, and the words the table prints instead of numbers

At high latitude the sunrise and sunset story stops being a story, and the tool switches to plain statements rather than manufacturing times. Tromsø on 21 June 2026 is flagged as midnight sun, both the sunrise and sunset cells read Never sets, the day length cell shows a dash, and the golden columns of the week table read All night, because the sun never drops to the 4° below the horizon that would end the band.

The December version is more interesting than a blank page. Tromsø on 21 December is flagged as polar night, both cells read Never rises, and yet the day card still reports a morning blue hour from 09:31 to 10:29 and a golden window pinned to solar noon at 11:42, because the sun sits just below the horizon rather than far below it. The week table compresses that case to Around midday. Reykjavík at the June solstice shows a third variant: the sun does set, at 00:04, but never drops 4° below the horizon, so the golden band runs all night and the blue hour is reported as absent because the sun never gets low enough for it. Each of those outcomes comes from the geometry detecting that a crossing simply does not happen that day, not from a special case bolted on afterwards. The rest of the date and time tools sit together on the calculators hub.

See it in action

Screenshot of the Golden Hour Calculator tool with a city picker spanning London, New York, Los Angeles, Mexico City, Sao Paulo, Reykjavik and more, working out the golden and blue hour windows around sunrise and sunset for the chosen date
Golden Hour Calculator mid-process: a city picker spanning London, New York, Los Angeles, Mexico City, Sao Paulo, Reykjavik and more, working out the golden and blue hour windows around sunrise and sunset for the chosen date.
Diagram: where the work happens on a SysFenix page that has no file input at all: the tool arrives as ordinary JavaScript inside the page, works the answer out on your own device and renders it in place, so the upload, queue and server-side record a typical online tool needs never happen
Where the work happens on a SysFenix page that has no file input at all: the tool arrives as ordinary JavaScript inside the page, works the answer out on your own device and renders it in place, so the upload, queue and server-side record a typical online tool needs never happen.

Frequently asked questions

Do the times follow the city I picked or the clock on my own machine?

The city. Every event is solved as a UTC instant first and only then rendered in that city's own IANA time zone, so choosing Sydney from a desk in Madrid gives Sydney wall-clock times. A line under the controls names the zone and its offset for that date, and adds an explicit note when that zone is not the one your device is running in.

Does the week table cope with a daylight saving change?

Yes, because the offset is resolved for each day rather than once for the block. Ask for the week beginning 22 October 2026 in London and the first three rows show sunrise at 07:36, 07:38 and 07:39 on UTC+01:00, then Sunday 25 October drops to 06:41 on UTC+00:00 as the clocks go back. The solar arithmetic is identical across that boundary; only the zone used for display changes.

Why is the sunset time earlier than the sunrise time for ReykjavĂ­k in June?

Because the cells show a clock time and never a date. On 21 June 2026 the ReykjavĂ­k sunset instant falls just after midnight, so the sunset cell reads 00:04 while sunrise reads 02:55. The day length line settles the ambiguity by reporting 21h 09m, which only works if that sunset belongs to the following morning.

How long does golden hour actually last?

It varies with latitude and season, and nothing here assumes sixty minutes. On 21 June 2026 the evening golden window runs about 83 minutes in London and about 44 minutes in Singapore, while New York on 21 March 2026 gets about 53 minutes. All three come from the same altitude band, simply crossed at different angles.

What does the tool show for a place inside the Arctic Circle?

Words rather than invented times. Tromsø on 21 June is flagged as midnight sun, its sunrise and sunset cells read Never sets, and the golden columns of the week table read All night. On 21 December the same place is flagged as polar night with Never rises, yet still reports a real morning blue hour from 09:31 to 10:29 and a low golden window pinned to the 11:42 solar noon.

Do I have to share my location to use this?

No. The page opens on a city from the list and is fully usable that way. The location button is opt-in, your browser asks before releasing anything, and the coordinates are fed once into the same arithmetic that runs for a city preset. If you decline, the page says so in plain text and leaves you on the city list.

Related tools