Skip to content

Changes to WEEKNUM and YEARFRAC #1316

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

Merged
merged 4 commits into from
Feb 19, 2020
Merged

Changes to WEEKNUM and YEARFRAC #1316

merged 4 commits into from
Feb 19, 2020

Conversation

oleibman
Copy link
Collaborator

The optional second parameter for WEEKNUM can take any of 10 values
(1, 2, 11-17, and 21), but currently only 1 and 2 are supported.
This change adds support for the other 8 possibilities.

YEARFRAC in Excel does not require that end date be before start date,
but PhpSpreadsheet was returning an error in that situation.

YEARFRAC third parameter (method) of 1 was not correctly implemented.
I was able to find a description of the algorithm, and documented
that location in the code, and implemented according to that spec.
PHPExcel had a (failing) test to assert the result of
YEARFRAC("1960-12-19", "2008-06-28", 1). This test had been dropped
from PhpSpreadsheet, and is now restored; several new tests have
been added, and verified against Excel.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

Why this change is needed?

As described above, extend support for WEEKNUM, and correct some problems in YEARFRAC.

The optional second parameter for WEEKNUM can take any of 10 values
(1, 2, 11-17, and 21), but currently only 1 and 2 are supported.
This change adds support for the other 8 possibilities.

YEARFRAC in Excel does not require that end date be before start date,
but PhpSpreadsheet was returning an error in that situation.

YEARFRAC third parameter (method) of 1 was not correctly implemented.
I was able to find a description of the algorithm, and documented
that location in the code, and implemented according to that spec.
PHPExcel had a (failing) test to assert the result of
YEARFRAC("1960-12-19", "2008-06-28", 1). This test had been dropped
from PhpSpreadsheet, and is now restored; several new tests have
been added, and verified against Excel.
Scrutinizer reported a very mysterious failure with no details.
project.metric_change("scrutinizer.test_coverage", < 0),
without even a link to explain what it is reporting.
It is possible that it was a complaint about code coverage.
If so, I have added some tests which will, I hope, eliminate the problem.
Responding to review from Mark Baker.
Travis CI reported problem with Calculation.php (which is not part
  of this change).
That was changed in master a few days ago
(delete some unused code).
Perhaps the lack of that change is the problem here.
Merging it manually.
@oleibman oleibman requested a review from MarkBaker February 12, 2020 05:21
@MarkBaker MarkBaker merged commit cb18163 into PHPOffice:master Feb 19, 2020
@MarkBaker
Copy link
Member

Thanks for the fixes, and for the improvements. The contribution is much appreciated

paulkned pushed a commit to paulkned/PhpSpreadsheet that referenced this pull request Mar 6, 2020
* Changes to WEEKNUM and YEARFRAC

The optional second parameter for WEEKNUM can take any of 10 values
(1, 2, 11-17, and 21), but currently only 1 and 2 are supported.
This change adds support for the other 8 possibilities.

YEARFRAC in Excel does not require that end date be before start date,
but PhpSpreadsheet was returning an error in that situation.

YEARFRAC third parameter (method) of 1 was not correctly implemented.
I was able to find a description of the algorithm, and documented
that location in the code, and implemented according to that spec.
PHPExcel had a (failing) test to assert the result of
YEARFRAC("1960-12-19", "2008-06-28", 1). This test had been dropped
from PhpSpreadsheet, and is now restored; several new tests have
been added, and verified against Excel.

* Add YEARFRAC Tests

Scrutinizer reported a very mysterious failure with no details.
project.metric_change("scrutinizer.test_coverage", < 0),
without even a link to explain what it is reporting.
It is possible that it was a complaint about code coverage.
If so, I have added some tests which will, I hope, eliminate the problem.

* Make Array Constant

Responding to review from Mark Baker.

* Merge with PR 1362 Bugfix 1161

Travis CI reported problem with Calculation.php (which is not part
  of this change).
That was changed in master a few days ago
(delete some unused code).
Perhaps the lack of that change is the problem here.
Merging it manually.
@oleibman oleibman deleted the datechanges branch April 28, 2020 04:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants