How time zones and daylight saving are handled
Every local time on this site — the world clock, the sunrise times, the tide times — is produced the same way, and it is deliberately not the obvious way.
No offsets are stored. Anywhere.
The tempting design is a table of cities and their UTC offsets. It is also wrong within about a year, because governments change daylight saving rules with little notice and every stored offset becomes a small lie until someone rebuilds the site.
What is stored instead is the IANA time zone name — America/Halifax, Asia/Kolkata, Australia/Lord_Howe. The offset is then asked for at the moment it is needed, from your own device's internationalisation engine, which is backed by the IANA database and updated by your operating system.
The practical consequence: when a country moves its clocks, these pages follow as soon as your device does, with no rebuild here at all.
Detecting daylight saving
There is no flag in the data saying "this zone uses DST". It is worked out, with a rule short enough to state completely:
1. Ask for the zone's offset on the 15th of each of the twelve months of the current year.
2. If all twelve are equal, the clocks there do not change. Say so and stop.
3. If they differ, those are the offsets the zone actually takes — name them.
4. Compare today's offset against the set to say which one the zone is on right now.
Twelve samples, not two. Sampling only January and July handles the southern hemisphere correctly — Australia's daylight saving is in January and the comparison never assumes which half of the year is which — but it misses a shift that happens in neither month. Africa/Casablanca is UTC+1 on both dates and falls back to UTC for about five weeks around Ramadan every year, so the two-sample rule told Casablanca's page its offset "holds all year", wrongly, for several weeks annually.
The wording follows from the offsets rather than from a "does it do DST" flag, for the same reason: Casablanca's shift is a Ramadan pause, not daylight saving, and calling it one would be a second wrong answer dressed as a right one.
Which page a zone links to
Around 2,300 place pages carry a one-line "it's 5:35 PM in Portland right now" strip, and each has to link somewhere sensible on the world clock. The resolution runs in three steps, and the link text changes with it — which is the point.
This city has a world clock page. The link names the city.
It does not, but its zone has a representative page. The link names the zone: "Pacific Daylight Time on the world clock". Portland has no page of its own and lands on Los Angeles, so promising "Portland on the world clock" would be a promise the destination cannot keep.
Neither. The link goes to the hub and says so.
Zones are matched first by exact IANA name, then by the daylight-saving-independent name the browser gives them — which is how America/Detroit finds the Eastern Time page without anyone maintaining a list of aliases.
The awkward cases, and what happens
One genuine limitation remains: twelve monthly samples describe the current year, and a shift shorter than a month that falls between two sample dates would still be missed. That is why the page states which offsets a zone takes rather than promising when it changes.