islamic-network / prayer-times Goto Github PK

AlsalamuAlykom,

Here it applies the high latitude adjustment if for example the time between Fajr and sunrise is greater than the night portion, should not the high latitude adjustment only applied if the times determination according to the calculation method respective angles is not possible?

I encountered an issue while using your library prayer-times in my Laravel 10 application (current version). When I run the command php artisan serve, it shows the following error:

After some investigation, I found that the PHP function gregoriantojd() used in line 533 of the PrayerTimes.php class is not recognized by the current PHP version. My current PHP version is:

The library works fine in Homestead, where the PHP version is:

Additional Information:
In addition, I noticed a discrepancy in line 533 of the PrayerTimes.php class . Specifically, it suggests receiving the year using $this->date->format('y'), but according to the PHP documentation, it should be received as $this->date->format('Y') to represent the four-digit year. Please consider updating this part of the code for consistency and compatibility.

Please advise on how to resolve this compatibility issue or if there is a recommended PHP version for using the prayer-times library.

Thank you!

As-salaamu alaykum,

I noticed that the Asr calculation uses the server's local time for the fractional component of the Julian day (date('i') + date('s')):

This means that the server can return different Asr times for the same API call, depending on when in the day the call is made (relative to the system time of the server).

For example, this randomly generated API call for a specific date and lat/lng. When I made the API call a few days ago at 17:33, the Asr time was 13:57. When I make the same call now (at 08:15), the Asr time is 13:59. All other times are identical, as one would hope.

I don't think the Asr time should change based on when the API call is made relative to the server's clock. I think the original PrayTimes calculation is correct here.