How to Keep Your Salah Schedule Accurate When You Cross US Time Zones

You land at LAX, open your prayer app, and it still thinks you are in New York. Maghrib has apparently passed, three hours before sunset. The fix takes about a minute, once you know which of five causes you are looking at.

Why your app still shows your departure city's times

Almost always the app is holding a stale location, not a stale clock. Prayer times are derived from the sun's position at a specific latitude and longitude, so change the coordinates and all five times move. An app that still believes you are in New York will serve New York's schedule with complete confidence.

Two mechanisms keep that old location alive. Apps commonly read a cached last-known position for speed, and Google's own documentation warns that the location getLastLocation() returns "may be of an arbitrary age." Background updates are then deliberately coarse: iOS significant-change monitoring fires only after roughly 500 metres of movement and no more than once every five minutes, and on Android, Doze and battery restrictions defer background work until the device properly wakes.

Offline mode compounds it. Muslim App serves prayer times without a connection for your saved location, but location search needs internet. Fly in airplane mode and you have both problems at once: no network to notice the new city, and a working offline schedule for the old one. What keeps working with no signal at all, and what quietly stops, is a subject of its own.

Diagnose it by which prayers are wrong

Start with which prayers are off, not how far off they are. A location or clock fault moves all five prayers together; a settings fault moves only the prayers that setting governs. Compare the app against the times for the city you are actually in, or against a printed timetable from a mosque near you.

The two settings rows carry no fixed range because the gap they produce is not a fixed quantity. Each convention uses its own twilight angle, published by AlAdhan, whose engine puts New York's Fajr on 14 July 2026 at 04:01 under ISNA, 03:37 under the Muslim World League and 03:24 under the Egyptian General Authority: 24 minutes apart from one, 37 from the other. Asr swings wider still, from 77 minutes at Anchorage in July to 16 there in December and 7 at Fairbanks at the solstice. Dhuhr and Maghrib do not move between conventions at all, which is why a 60-minute error across all five prayers is a clock fault rather than a settings one.

Fix it: two settings, in this order

Two settings account for nearly every case, and both have to be right. The phone needs to know which time zone it is in, and the app needs to know where you are. Correcting the second without the first still leaves you an hour out.

1. Let the phone find its own time zone

On iPhone, open Settings → General → Date & Time and turn on Set Automatically. Apple is explicit about the dependency: the time zone "is set automatically, but if you don't have Location Services turned on or you don't have service, you can change it manually." On Android the equivalent sits under Settings → System → Date & time.

A phone with no connectivity cannot re-detect its zone. If you flew in airplane mode, the clock may only correct itself once you rejoin a network, and airport Wi-Fi is enough.

2. Give the app a fresh, precise location

In Muslim App, tap Update Location, or turn on automatic location detection so the app follows your device's GPS. You can also search for and select your city manually, which is the right move when you want the schedule pinned to a place rather than to wherever the phone happens to be.

Check the permission itself, not just the toggle inside the app. iOS has a separate Precise Location switch that can be off while location permission is on, and Android draws the same distinction. Android's approximate mode resolves you only to an area of about three square kilometres, which is enough to sit on the wrong side of a time zone boundary and more than enough to skew the Qibla.

The US-specific traps

Three quirks of American timekeeping catch apps that trust a stale time zone: Daylight Saving Time, the states that ignore it, and Alaska, where the calculation itself stops working in summer. Each produces a different signature, and each has a different fix.

Daylight Saving Time: the "exactly one hour" signature

An error of exactly 60 minutes across all five prayers is a time zone fault, not a calculation fault. In the US, DST runs from the second Sunday in March to the first Sunday in November: 8 March to 1 November in 2026, and 14 March to 7 November in 2027. The twice-yearly change remains federal law: the House passed the Sunshine Protection Act on 14 July 2026, but it still needs the Senate and the president's signature, so the dates above stand.

Arizona does not change its clocks

Most of Arizona has stayed on Mountain Standard Time year-round since 1968, and Hawaii does not observe DST either: NIST lists both exemptions. In summer, Phoenix keeps Mountain Standard Time while Denver moves to Mountain Daylight Time, so Phoenix and Los Angeles read the same clock, and an app that assumed Phoenix follows Denver reads an hour late. Arizona is not uniform either: the Navajo Nation observes DST, while the Hopi Reservation enclosed within it does not.

Alaska breaks the calculation itself

Alaska is the only US state where the standard method fails outright. Fajr and Isha are defined by the sun reaching a set angle below the horizon, 15° under the convention the Fiqh Council of North America recommends for the United States. At midsummer the sun stops reaching that angle above roughly 51.6°N. No part of the contiguous US gets that far north, but Anchorage sits at 61.2°N, Fairbanks at 64.8°N and Utqiaġvik at 71.3°N, so for them the times are simply undefined.

Apps respond with a high-latitude rule, which estimates the times rather than computing them. The choice is not cosmetic. For Anchorage (61.22°N, 149.90°W) on 14 July 2026, holding the ISNA base method constant and changing only that rule, the AlAdhan engine gives Fajr at 02:06 under Middle of the Night, 03:28 under Angle-Based, and 04:03 under One-Seventh of the Night: a spread of nearly two hours. Only the Angle-Based figure depends on the base method; pick a different one and that middle number moves.

Scholars differ on which rule to follow, and mosques in Alaska have not settled on a single answer. That makes it a question for your local mosque or scholar rather than a setting to guess at.

What the calculation settings change

The calculation method sets the twilight angle used for Fajr and Isha, and the madhhab setting decides when Asr begins. Both are location-independent, so both were right before you boarded and are still right now. Neither is what changed when you flew. How a timetable is computed in the first place is a separate subject, covered on its own.

Muslim App lets you choose between calculation methods from different Islamic authorities, apply madhhab and latitude adjustments, and add or subtract minutes from any individual prayer so the schedule lines up with your local mosque. Changing a method does not make the times more correct: it selects which established convention the app follows, and the one to match is your mosque's. Why two apps in the same city disagree is a separate subject, covered on its own.

Before you next fly

Turn on automatic time zone, allow precise location, and open the app once after you land. That routine removes every failure mode above in about a minute. If you would rather not depend on the phone, check the times for the city you are actually in before you travel, or set the location manually to Los Angeles, or wherever you are heading, the night before.

Muslim App reads prayer times from your device's GPS, works offline once your location is saved, and lets you tune the calculation method, madhhab and per-prayer minutes to match your mosque. Download it for iOS or Android and set it up before your next trip.