php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61185 jdtojewish return values incompatible with cal_days_in_month on non-leap years
Submitted: 2012-02-26 09:10 UTC Modified: 2016-06-18 11:38 UTC
Votes:2
Avg. Score:3.5 ± 1.5
Reproduced:0 of 1 (0.0%)
From: php-bugs at shimi dot net Assigned: cmb (profile)
Status: Duplicate Package: Calendar related
PHP Version: 5.4.0RC8 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: php-bugs at shimi dot net
New email:
PHP Version: OS:

 

 [2012-02-26 09:10 UTC] php-bugs at shimi dot net
Description:
------------
Preamble:

Please bear with me for the long explanation, it is my reasoning for the request I'm going to give in the end.

I'm pretty sure the code I'm testing now worked a few years ago; I have specific code that actually checks if the Jewish year is leap, and if so, add 1 month to all calculations after the 6th month if the year is leap.

Now my code is broken. Regardless if it really worked in the past or not, I see an incompatibility between two calendar functions, which I think should be aligned together.

My code calculates the dates of many Jewish events, according to the Jewish calendar. For those who are not familiar with the Jewish calendar - not every year has the same amount of months. If the (Jewish year % 19) is 0, 3, 6, 8, 11, 14 or 17, then the year is "leap" (I don't have a better word in English), and an additional month is added between the 5th month (Shvat) and the 6th month (Adar). The new month added is also called "Adar" (and denoted "Adar A", while the original Adar becomes the second, and denoted "Adar B", so the holiday that we have in Adar every year, remains in B).

Now, at the moment, we're in an Adar month (which is why the bug popped out), but this is not a leap year (Jewish year now is 5772 % 19 = 15), so we have only one Adar month.

Now, as memory serves me (and as written in my code), cal_days_in_month could accept 1-12 as valid month on non-leap years, and 1-13 on leap years. My code has tests for those things, and acted accordingly. Now, it appears, that cal_days_in_month always accepts a 1-13 value, and simply expect the programmer to jump over the 6th month, returning "0" if there was no Adar A added before the regular Adar.

This is OK! Actually, it makes all my calculations of leap years - redundant.

The problem is - that even though cal_days_in_month understand that the _current_ month is actually the 7th (as we "skipped" the 6th of 13 of a leap year), jdtojewish, the function that gives you those dates in the first place, says that we're in the 6th month...

I think that if cal_days_in_month thinks there is no 6th month this year, jdtojewish should never return the number "6" for this year.

[p.s. example code will not show the mentioned problem in ~28 days when the Hebrew month changes, but will probably return a wrong day count...]

Test script:
---------------
Code:

<?php
  list($jewishmonth, $jewishday, $jewishyear) = explode('/', jdtojewish(gregoriantojd(date('m'), date('d'), date('y'))));
  echo "Jewish month is $jewishmonth. How many days do we have this month? " . cal_days_in_month(CAL_JEWISH, $jewishmonth, $jewishyear) . "\n";
?>




Expected result:
----------------
Jewish month is 7. How many days do we have this month? 29

Actual result:
--------------
Jewish month is 6. How many days do we have this month? 0

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-07-12 13:00 UTC] eitan at mosenkis dot net
Duplicate of 54254
 [2016-06-18 11:38 UTC] cmb@php.net
-Status: Open +Status: Duplicate -Assigned To: +Assigned To: cmb
 [2016-06-18 11:38 UTC] cmb@php.net
Indeed, that is a duplicate of bug #54254.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 02:01:28 2024 UTC