DevOps reference: SKY-245
Hi Stargazer,
Are you still having issues with SkySafari on Android? If so, please provide the following info:
App and version. See Help > scroll to the bottom.
Android OS.
Device make and model
Screenshot(s) that demonstrate the issue.
Thanks!
I cant make sense of the sunset time compared with other applications (Stellarium) or python astronomy libraries like Skyfeild. I can't explain the difference of 33 minutes with time zone, refraction, delta t.
I have now isolated the issue much further, and I think the new tests should make it reproducible.
## Clear summary
The astronomical calculations themselves appear to be correct. SkySafari, Stellarium, and Skyfield all agree on the sunset in Mecca on **25 September 1908** when the time is consistently expressed using a fixed **UTC+03:00** offset.
The problem is specifically with **historical local-time conversion in SkySafari on Android**.
For the same observing location in SkySafari:
* Mecca
* Latitude ≈ 21.4225° N
* Longitude ≈ 39.8262° E
* Elevation 333 m
* SkySafari observing-site timezone explicitly set to **+3.0 hours**
* Date: **25 September 1908**
I obtained these results depending only on the Android system timezone:
| Android system timezone | Time entered in SkySafari | UTC shown by SkySafari | Chart time after closing dialog |
| -------------------------- | ------------------------: | ---------------------: | ------------------------------: |
| Asia/Qatar | 18:14:40 | 14:48:32 | 17:48:32 |
| Asia/Riyadh / Saudi Arabia | 18:14:40 | 15:07:48 | 18:07:48 |
| Fixed GMT+03:00 | 18:14:40 | 15:14:40 | 18:14:40 |
The offsets are very significant:
* `Asia/Qatar` in 1908 historically corresponds to approximately **UTC+03:26:08**
* `Asia/Riyadh` in 1908 historically corresponds to approximately **UTC+03:06:52**
* fixed `GMT+03:00` is, of course, exactly **UTC+03:00**
SkySafari reproduces those historical offsets **to the second**.
For example:
18:14:40 − 03:26:08 = **14:48:32 UTC**
which is exactly what SkySafari displayed when Android was set to Qatar.
Changing Android to Saudi Arabia gave:
18:14:40 − 03:06:52 = **15:07:48 UTC**
again exactly what SkySafari displayed.
And when Android was changed to a fixed GMT+03:00:
18:14:40 − 03:00:00 = **15:14:40 UTC**
which is finally correct for the +3.0 observing-site setting.
So the Android system timezone is clearly affecting the interpretation of a manually entered historical date, even though the SkySafari observing site itself is explicitly configured as **GMT+3.0**.
## Full explanation
Originally I noticed what looked like a very large astronomical discrepancy.
SkySafari on Android placed the Sun near the horizon in Mecca at approximately:
**17:48 on 25/09/1908**
while Stellarium and my Skyfield calculations appeared to give approximately:
**18:14–18:21**
At first I suspected Dynamic Time / ΔT, but that turned out not to be the cause.
I disabled **Dynamic Time** in SkySafari and repeated the test. The 26-minute error remained essentially unchanged.
I then noticed something important in SkySafari's Advanced Date & Time screen.
With Android configured for Qatar, I entered:
**25/09/1908 18:14:40**
but SkySafari displayed:
**UTC 14:48:32**
even though the observing site inside SkySafari was explicitly configured as **+3.0 hours from GMT**.
A fixed UTC+3 conversion should have been:
**18:14:40 − 3:00:00 = 15:14:40 UTC**
Instead SkySafari subtracted:
**3:26:08**
This is exactly the historical Local Mean Time offset associated with Qatar for that period.
I then changed only the Android system timezone to Saudi Arabia/Riyadh and repeated the same test.
SkySafari now showed:
**UTC 15:07:48**
The difference from the entered time is:
**3:06:52**
which exactly matches historical Riyadh Local Mean Time for 1908.
The displayed sky time also moved by exactly the difference between the two historical offsets:
03:26:08 − 03:06:52 = **19 minutes 16 seconds**
The chart changed from about:
**17:48:32**
to:
**18:07:48**
which is also a difference of exactly:
**19 minutes 16 seconds**
Finally, I changed Android itself to a fixed:
**GMT+03:00**
and repeated the experiment.
Now SkySafari behaved correctly:
Entered local time:
**18:14:40**
SkySafari UTC:
**15:14:40**
Chart time:
**18:14:40**
This also brought SkySafari into essentially perfect agreement with Stellarium and Skyfield.
## Stellarium cross-check
I performed the same comparison in Stellarium 26.2.
When Stellarium was configured with the named historical timezone:
**Asia/Riyadh**
it showed the same physical solar position at about:
**18:21:29**
When Stellarium was instead configured with a fixed:
**UTC+03:00**
the same solar position occurred at about:
**18:14:37**
The difference is exactly:
**6 minutes 52 seconds**
which again corresponds to:
**UTC+03:06:52 − UTC+03:00:00**
So Stellarium is correctly distinguishing between:
1. historical `Asia/Riyadh` Local Mean Time, and
2. a deliberately chosen fixed UTC+3 offset.
That helped confirm that the astronomical position was not the problem.
With fixed UTC+3, the programs agree very closely:
* SkySafari: about **18:14:40**
* Stellarium: about **18:14:37 / set ≈18:15**
* Skyfield: about **18:14**
So there is no meaningful ephemeris disagreement here.
## Important iOS comparison
I then repeated the same experiment in **SkySafari Plus 8.0.3 (1205) on iPadOS 26.5.2**.
The iPad's system timezone was set to:
**Asia/Qatar / Doha**
The observing site inside SkySafari was still:
**Mecca, Standard Time Zone +3.0**
I entered:
**25/09/1908 18:14:40**
and the iOS version correctly displayed:
**UTC 15:14:40**
The sky chart also remained at:
**18:14:40**
So the iOS version did **not** apply Qatar's historical +03:26:08 offset.
This is different from the Android version, where the Android system timezone affected the conversion.
The Android version I tested is:
**SkySafari 8.1.0.10**
package:
`com.simulationcurriculum.skysafari8pro`
The iPad version is:
**SkySafari Plus 8.0.3 (1205)**
Therefore I cannot yet tell whether the difference is strictly:
* Android vs iOS,
* SkySafari 8.1.0.10 vs 8.0.3,
* or both.
But the Android behavior is completely reproducible.
## What appears to be happening
I obviously cannot see SkySafari's internal code, so this part is an inference based on the tests.
It appears that on Android, when a historical calendar date is entered manually, SkySafari is allowing the **Android system timezone database** to convert that local date/time to UTC.
For dates before standardized civil time, Android's named zones such as `Asia/Qatar` and `Asia/Riyadh` return historical Local Mean Time offsets.
However, SkySafari also has its own observing-site field:
**“Standard Time Zone (hours from GMT)”**
which I explicitly set to:
**+3.0**
The resulting behavior therefore appears to mix two different timezone concepts:
* the Android device's historical named-zone offset when interpreting the entered date/time;
* SkySafari's own +3.0 observing-site offset when displaying the chart.
That produces the shift.
For Qatar in 1908, for example:
Entered:
**18:14:40**
Android historical Qatar conversion:
**−03:26:08**
UTC:
**14:48:32**
Then SkySafari's site offset:
**+03:00:00**
Chart:
**17:48:32**
That exactly reproduces what I observed.
## Expected behavior
If a SkySafari observing site explicitly has:
**Standard Time Zone = +3.0**
then I would expect a manually entered local time of:
**18:14:40**
to correspond to:
**15:14:40 UTC**
regardless of whether the Android device's own timezone happens to be Qatar, Riyadh, New York, etc.
If SkySafari instead intends to use the operating system's historical named timezone rules, then the observing-site `Standard Time Zone` field should presumably not override or conflict with that behavior.
The fact that the iOS version honors the explicitly entered +3.0 offset while Android does not suggests this may be platform-specific.
## Easy reproduction test
On an Android device:
1. Create an observing site in Mecca with timezone **+3.0**.
2. Set Android's system timezone to **Qatar**.
3. In SkySafari enter **25/09/1908 18:14:40**.
4. Open Advanced Date & Time.
5. Observe that UTC becomes approximately **14:48:32**, corresponding to UTC+03:26:08 rather than +03:00.
6. Change Android's system timezone to **Saudi Arabia/Riyadh** and repeat.
7. UTC becomes approximately **15:07:48**, corresponding to UTC+03:06:52.
8. Change Android to a fixed **GMT+03:00** offset.
9. Repeat again.
10. UTC now becomes the expected **15:14:40**.
The astronomical position of the Sun remains consistent; it is the civil-time conversion that changes.
I hope these tests help isolate the issue, because the exact match to the historical Qatar and Riyadh offsets seems especially diagnostic.
Thank you for this info.