php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49558 Sunrise Problems around 91 degree zenith
Submitted: 2009-09-15 05:51 UTC Modified: 2009-09-16 07:03 UTC
From: eclipsechasers2 at yahoo dot com Assigned:
Status: Closed Package: Date/time related
PHP Version: 5.2.10 OS: *
Private report: No CVE-ID: None
 [2009-09-15 05:51 UTC] eclipsechasers2 at yahoo dot com
Description:
------------
Script showing times for series of zeniths from 90.0 to 92.0 by 0.1 should show time uniformly decreasing (earlier) as zenith gets larger. This is true for most values. However, 91.1 shows a later time than 91.0, as does 91.2; this would happen only if earth changed its direction of rotation.

Reproduce code:
---------------
<?php
$gregyear = 2009; $gregmonth = 3; $gregday = 20;
$location = "San Francisco"; $latitude = 37.787; $longitude = -122.447;
$timezone = "America/Los_Angeles";
$gregmonthname = JDMonthName(cal_to_jd(CAL_GREGORIAN,$gregmonth,1,2000),1);
$jd = gregoriantojd($gregmonth, $gregday, $gregyear);
  $weekday = jddayofweek($jd,0);
  echo "<b>$gregyear $gregmonthname $dd  - " . jddayofweek($jd,1) . " - ";
  echo "Latitude $latitude Longitude $longitude Time Zone $timezone Location $location</b>\n";
  $ts = $gregyear . "-" . $gregmonth . "-" . $dd . " 06:00:00";
  $strts = strtotime($ts);
  $gmto = -8;
  for ($deg = 90; $deg <= 92; $deg += .1) {
    $sunris0 = date_sunrise($strts,SUNFUNCS_RET_TIMESTAMP, $latitude, $longitude, $deg, $gmto);
    printf("<br>%02.1f %s\n",$deg,date("g:i:sa",$sunris0));
    }
?> 

Expected result:
----------------
Unsure of exact result (can't do these calculations in my head), but the times on each line should be earlier than the line above.

Actual result:
--------------
2009 March - Friday - Latitude 37.787 Longitude -122.447 Time Zone America/Los_Angeles Location San Francisco
90.0 7:28:40am
90.1 7:28:05am
90.2 7:27:30am
90.3 7:26:56am
90.4 7:26:21am
90.5 7:25:46am
90.6 7:25:11am
90.7 7:24:37am
90.8 7:24:02am
90.9 7:23:28am
91.0 7:22:53am
91.1 7:23:52am ** Either these 2 values, or the 2 above, are wrong.
91.2 7:23:18am
91.3 7:22:43am
91.4 7:22:08am
91.5 7:21:34am
91.6 7:20:59am
91.7 7:20:25am
91.8 7:19:51am
91.9 7:19:16am
92.0 7:18:42am

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-09-15 17:18 UTC] colin at viebrock dot ca
I'd say that all the times from 91 degrees onward are off.  Graphing the 
data shows it "jumps" at that point, but is smooth before and after.

Could it be some error related to line 3930 in ext/date/php_date.c

rs = timelib_astro_rise_set_altitude(t, longitude, latitude, altitude, 
altitude > -1 ? 1 : 0, &h_rise, &h_set, &rise, &set, &transit);

Altitude is 90-zenith, so when you get to 91, the code would set that 
param from 0 to 1 ... which I think means it calculates the twilight 
time instead of sunrise/set.  I would say this param should always be 1, 
if you are calculating sunrise/set (see note on line 187 of 
ext/date/lib/astro.c).
 [2009-09-15 17:21 UTC] colin at viebrock dot ca
TYPO IN LAST COMMENT - SHOULD READ:

Altitude is 90-zenith, so when you are below 91, the code sets that 
param to 0 ... which I think means it calculates the twilight 
time instead of sunrise/set.  I would say this param should always be 1 
if you are calculating sunrise/set (see note on line 187 of 
ext/date/lib/astro.c).
 [2009-09-15 17:39 UTC] kr dot shaishav at gmail dot com
i think the bug is being caused by this 
altitude > -1 ? 1:0 ,line 3930 in php_date.c. 
becoz of this upper_limb correction is being applied here....
if (upper_limb) {altit -= sradius;} line 253, astro.c 

the series gets advanced because of the altit-=sradius;. 
and hence the anamoly. i dont knw if its a bug. don't know about the upper limb correction and why is it being selectively beyond -1 applied. but the bug can be removed if we remove the uppr_limb if code. or add it without an if. and if the correction is correctly applied, then i guess thats the way it is.not a bug.
 [2009-09-15 17:43 UTC] rasmus@php.net
Hardcoding that upper_limit to correction flag to either 0 or 1 does remove the quirk in the series.  So, is it correct that for the sunrise function we should just peg it at 1?
 [2009-09-15 18:11 UTC] kr dot shaishav at gmail dot com
This is from the original sun.c file
Written as DAYLEN.C, 1989-08-16
Modified to SUNRISET.C, 1992-12-01
(c) Paul Schlyter, 1989, 1992
Released to the public domain by Paul Schlyter, December 1992
Portions Modified to SUNDOWN.NLM by Cliff Haas 98-05-22

the comment states
/*         upper_limb: non-zero -> upper limb, zero -> center       */
/*               Set to non-zero (e.g. 1) when computing rise/set   */
/*               times, and to zero when computing start/end of     */
/*               twilight.                                          */

Therefore, if we are calculating sunrise-sunset time the value of upper_limb will be set to permanently non zero.
If twilight time is needed then it has to be 0.


(PS - just for clearing what this upper limb is. Sunrise happens when the sun's centre is visible. But for the twilight to occur, the sun's top should come over the horizon. that means,centre angle - sradius:)
 [2009-09-15 19:27 UTC] colin at viebrock dot ca
The comments from the sun.c file are also in PHP's ext/date/lib/astro.c 
(around line 187).

From my reading of things, this upper-limb value should be pegged at 1 
in php_date.c

Which, of course, means that most systems have been generating 
sunrise/set times that are off by about 26 seconds.  Think of all the 
angry emails you're gonna get from The Weather Network!
 [2009-09-15 20:28 UTC] svn@php.net
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=288354
Log: Fix bug #49558
And as Colin mentioned in the bug report, this means date_sunrise()
and date_sunset() have been off by 26 seconds in most cases until now.
 [2009-09-15 20:34 UTC] svn@php.net
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=288356
Log: Fix for bug #49558 for 5.2 and HEAD as well.
 [2009-09-16 07:03 UTC] rasmus@php.net
Fixed in SVN
 [2009-09-26 00:54 UTC] svn@php.net
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=288834
Log: Refix bug #49558 as per bug #49676
 [2009-10-09 18:59 UTC] svn@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=289441
Log: - Merege: Fix bug #49558 And as Colin mentioned in the bug report, this means date_sunrise() and date_sunset() have been off by 26 seconds in most cases until now
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Wed Sep 19 18:01:27 2018 UTC