Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bug 54254 #128

Closed
wants to merge 3 commits into from
Closed

Fix bug 54254 #128

wants to merge 3 commits into from

Conversation

emosenkis
Copy link
Contributor

Brings jdtojewish in line with cal_days_in_month (and with the way the Jewish calendar is generally expected to work) by skipping Adar I in non-leap years instead of Adar II - see http://en.wikipedia.org/wiki/Hebrew_calendar

@smalyshev
Copy link
Contributor

Not sure about this patch, since month names are not according to wiki anyway - 1st month should be Nisan, and Adar/AdarII should be 12th, also in non-leap years it should be just "Adar". Though you are right that second Adar is the same Adar as in non-leap years. But I think it'd be better if it were called by right name.

@emosenkis
Copy link
Contributor Author

For the numbering, see
http://en.wikipedia.org/wiki/Hebrew_calendar#Names_of_months - for
almost all purposes, Tishrei is the first month of the year.
"The day most commonly referred to as the "New Year" is 1 Tishrei,
which actually begins in the seventh month of the ecclesiastical year.
On that day the formal New Year for the counting of years (such as
Shmita and Yovel), Rosh Hashanah ("head of the year") is observed.
(see Ezekiel 40:1, which uses the phrase "beginning of the year".)
This is the civil new year, and the date on which the year number
advances." etc.

As for the names, I agree that ideally the month should be called Adar
in non-leap years, but my C isn't very good and it seemed far from
trivial to make that change. This patch addresses two issues, though:
first, that the month in a leap year should be Adar II instead of Adar
I (this is relevant because the holiday of Purim occurs each year in
Adar, and Adar II in leap years, so the clear expectation is that Adar
I should be the one that only exists in leap years. The second,
related issue is that in a non-leap year, the unpatched functions will
return 6, or Adar I for the month, while cal_days_in_month(CAL_JEWISH,
6, 5772) = 0, implying that the current month has zero days (this is
because cal_days_in_month correctly believes that Adar II exists in a
non-leap year and Adar I does not). After this patch, jdtojewish and
cal_days_in_month are consistent, so the current month is never one
with zero days (since both agree that Adar I occurs only in leap
years, which, again, is the common expectation of people familiar with
the Jewish calendar).

On Sat, Jul 14, 2012 at 9:50 PM, Stanislav Malyshev
[email protected]
wrote:

Not sure about this patch, since month names are not according to wiki anyway - 1st month should be Nisan, and Adar/AdarII should be 12th, also in non-leap years it should be just "Adar". Though you are right that second Adar is the same Adar as in non-leap years. But I think it'd be better if it were called by right name.


Reply to this email directly or view it on GitHub:
#128 (comment)

@smalyshev
Copy link
Contributor

I see what you mean. I'll try to see if I can fix the Adar issue. Could you also add test for the cal_days_in_month() issue and its interaction with jdtojewish()?

@emosenkis
Copy link
Contributor Author

I'm not sure that additional tests are necessary for cal_days_in_month

  • its behavior has actually been correct all along, it's just that the
    bug with jdtojewish was magnified when its output was used as input
    for cal_days_in_month (because cal_days_in_month was aware that Adar I
    doesn't exist in non-leap years, but jdtojewish and other functions
    calling the same C function were giving Adar I as the month). I did
    add another commit bringing the documentation in jewish.c in line with
    the updated code.

On Sat, Jul 14, 2012 at 11:13 PM, Stanislav Malyshev
[email protected]
wrote:

I see what you mean. I'll try to see if I can fix the Adar issue. Could you also add test for the cal_days_in_month() issue and its interaction with jdtojewish()?


Reply to this email directly or view it on GitHub:
#128 (comment)

@emosenkis
Copy link
Contributor Author

Ping

@smalyshev
Copy link
Contributor

I was just thinking about the test showing interaction between cal_days_in_month and jdtojewish to see that it returns correct result in every combination of cases.

@emosenkis
Copy link
Contributor Author

So maybe a test that prints the number of days in every month for a two year span including both a leap and a non-leap year and checks that they're all correct?

@smalyshev
Copy link
Contributor

sounds good

@emosenkis
Copy link
Contributor Author

Test added. Are you still planning to fix the Adar name issue? It seems the only way is to explicitly check anywhere that month names are returned (in English or Hebrew) whether month=7 and it's a leap year - it could be done by having Adar and Adar II have different month numbers, but that would break BC and generally be a poor solution. I'm not sure whether the extra name can safely be added to the arrays that hold all the names currently without side effects, but it could just be stored in its own variable since array indexing won't add anything here.

@smalyshev
Copy link
Contributor

Please check out this pull: #149
It integrates your fixes and improves display of Adar month.

@php-pulls
Copy link

Comment on behalf of stas at php.net:

merged

@php-pulls php-pulls closed this Aug 7, 2012
salathe pushed a commit to salathe/php-src that referenced this pull request Sep 9, 2013
salathe pushed a commit to salathe/php-src that referenced this pull request Sep 9, 2013
* PHP-5.5:
  Fixed issue php#128 (opcache_invalidate segmentation fault)
php-pulls pushed a commit that referenced this pull request Sep 16, 2013
php-pulls pushed a commit that referenced this pull request Sep 19, 2013
… PHP-5.5

# By Adam Harvey (3) and others
# Via Adam Harvey (2) and Michael Wallner (1)
* 'PHP-5.5' of https://git.php.net/repository/php-src:
  fix broken sha2 configure tests
  Fixed minor bug in test.
  Move NEWS entries to correct version
  Fix bug #64782: SplFileObject constructor make $context optional
  Fix bug #65502: DateTimeImmutable::createFromFormat returns DateTime
  Fix bug #65548: Comparison for DateTimeImmutable doesn't work
  Tinker with the wording of the short_open_tag description.
  Fix NEWS: these commits were after 5.5.4 was branched and will be in 5.5.5.
  Handle CLI server request headers case insensitively.
  ensure that the defined interpolation method is used by the generic scaling functions
  Fixed issue #128 (opcache_invalidate segmentation fault)
  5.4.21 now
php-pulls pushed a commit that referenced this pull request Sep 19, 2013
… PHP-5.5

# By Xinchen Hui (2) and Michael Wallner (1)
# Via Michael Wallner
* 'PHP-5.5' of https://git.php.net/repository/php-src:
  double test timeout for travis
  Add test for ISSUE #128
  Fixed bug #65665 (Exception not properly caught when opcache enabled)
php-pulls pushed a commit that referenced this pull request Sep 19, 2013
# By Michael Wallner (3) and others
# Via Michael Wallner (2) and Xinchen Hui (2)
* 'master' of https://git.php.net/repository/php-src:
  use 65k of data to get a more explicit result
  double test timeout for travis
  this test is fragile on travis, let's see why
  Add test for ISSUE #128
  Fixed bug #65665 (Exception not properly caught when opcache enabled)
  Save a TSRMLS_FETCH() for zval_ptr_dtor in executor
php-pulls pushed a commit that referenced this pull request Sep 27, 2013
* 'master' of https://git.php.net/repository/php-src:
  ensure that the defined interpolation method is used by the generic scaling functions
  Fixed issue #128 (opcache_invalidate segmentation fault)
  5.5.5 now
php-pulls pushed a commit that referenced this pull request Sep 27, 2013
* 'master' of https://git.php.net/repository/php-src:
  use 65k of data to get a more explicit result
  double test timeout for travis
  this test is fragile on travis, let's see why
  Add test for ISSUE #128
  Fixed bug #65665 (Exception not properly caught when opcache enabled)
  Save a TSRMLS_FETCH() for zval_ptr_dtor in executor
weltling pushed a commit to weltling/php-src that referenced this pull request Oct 16, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants