This bug also happens on php 5.3.3 with same configure line in my post above.

It happens on php 5.3.3 too.

I figured out a workaround to this bug. 
you have to add -1 day to subtract one day from sunrise and sunset times. 


if ($offset >= 12 && strcmp(date_default_timezone_get(), "Pacific/Tarawa") != 0) {
echo "+12 GMT workaround done<br>";
$sunrise = strtotime('-1 day', $sunrise);
$sunset = strtotime('-1 day', $sunset);
$csunrise = strtotime('-1 day', $csunrise);
$csunset = strtotime('-1 day', $csunset);
$nsunrise = strtotime('-1 day', $nsunrise);
$nsunset = strtotime('-1 day', $nsunset);
$asunrise = strtotime('-1 day', $asunrise);
$asunset = strtotime('-1 day', $asunset);
}

I need to test on time zones that are -12 in offsets 
might have to do +1 day on that offset.

PHP 5.3.15 Also has this issue though I don't believe it is related to the timezone being +12 or over

Keeping the timezone the same I changed the longitude value from 175 to 180 in 0.25 increments and found the sunrise/set values jump to the next day at different longitudes according to the time of the year.


Checking for the sunrise time on Oct 1st 2013 10:35 (NZ summer time) at longitude 177.25 gets 2013-10-01T06:45:18+13:00 but shift the longitude to 177.5 at the sunrise is reported as 2013-10-02T06:44:18+13:00

Checking for the sunrise time on Oct 31st 2013 10:35 (NZ standard time) at longitude 175.75 gets 2013-10-31T06:09:32+13:00 but shift the longitude to 176 at the sunrise is reported as 2013-11-01T06:08:32+13:00

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

The same problem happens on PHP7.3

A snippet of code that shows the issue could be:
<?php
        $dateTime = new DateTime('2013-10-01T10:35:00.000+13:00');
        $timestamp = $dateTime->getTimestamp();

        $sunInfo = date_sun_info($timestamp, -37.6908, 177.25);
        $sunInfo_2 = date_sun_info($timestamp, -37.6908, 177.50);

        echo $timestamp."<br>";

        echo "Sunrise for longitude 177.25: ".$sunInfo['sunrise']."<br>";
        echo "Sunrise for longitude 177.50: ".$sunInfo_2['sunrise']."<br>";
?>
which outputs:
1380576900
Sunrise for longitude 177.25: 1380476829
Sunrise for longitude 177.50: 1380563169


The sunrise for long 177.25, when transformed a readable value is:
GMT: Sunday, September 29, 2013 5:47:09 PM
Your time zone: Monday, September 30, 2013 6:47:09 AM GMT+13:00 DST

The sunrise for long 177.50, becomes:
GMT: Monday, September 30, 2013 5:46:09 PM
Your time zone: Tuesday, October 1, 2013 6:46:09 AM GMT+13:00 DST

As you can notice, the seed timestamp for both is the same, the only difference is the longitude value. But we still get results for the next day.

This was reproduced using the latest PHP7.3 docker image (using alpine linux), also can be reproduced copying the provided code on http://phpfiddle.org/ (I don't know what environment they use). 
This also happened on our old PHP5.6 servers using CentOS so it looks like is not OS/PHP version dependent, but an actual bug on the code.

Shall the behaviour exposed were intended, I would appreciate some sort of explanation regarding the why is expected.