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

Invalid date calendar format detection while loading several spreadsheets #1036

Closed
K0nias opened this issue Jun 26, 2019 · 2 comments · Fixed by #4071
Closed

Invalid date calendar format detection while loading several spreadsheets #1036

K0nias opened this issue Jun 26, 2019 · 2 comments · Fixed by #4071

Comments

@K0nias
Copy link

K0nias commented Jun 26, 2019

This is:

- [x] a bug report
- [ ] a feature request
- [ ] **not** a usage question (ask them on https://stackoverflow.com/questions/tagged/phpspreadsheet or https://gitter.im/PHPOffice/PhpSpreadsheet)

I came across this issue while I was writing tests with loading several spreadsheets and some datetime values was clearly invalid.

What is the expected behavior?

Loading numerious xlsx files should not share global state. Problematic is \PhpOffice\PhpSpreadsheet\Shared\Date::$excelCalendar

Problematic code https://github.com/PHPOffice/PhpSpreadsheet/blob/master/src/PhpSpreadsheet/Reader/Xlsx.php#L662

What is the current behavior?

\PhpOffice\PhpSpreadsheet\Shared\Date::$excelCalendar configuration can be shared across multiple spreadsheets

What are the steps to reproduce?

<?php

include 'vendor/autoload.php';

$reader = new \PhpOffice\PhpSpreadsheet\Reader\Xlsx();

// this method call config global value of \PhpOffice\PhpSpreadsheet\Shared\Date::setExcelCalendar
$reader->load(/* load file with set $xmlWorkbook->workbookPr and with workbookPr['date1904'] */);

// second load of another spreadsheet can be problematic if spreadsheet doesnt have "workbookPr" element. Then
// previously configurated global value of \PhpOffice\PhpSpreadsheet\Shared\Date::$excelCalendar is used

$reader->load(/* load file with missing $xmlWorkbook->workbookPr */);

working example with testing data can be found on gist

Which versions of PhpSpreadsheet and PHP are affected?

1.7.0

but referenced code is 3-4 years old so it could be many versions

@stale
Copy link

stale bot commented Aug 25, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is still an issue for you, please try to help by debugging it further and sharing your results.
Thank you for your contributions.

@stale stale bot added the stale label Aug 25, 2019
@stale stale bot closed this as completed Sep 1, 2019
@oleibman
Copy link
Collaborator

Reopening, to be closed properly by a PR which will fix the problem.

@oleibman oleibman reopened this Jun 23, 2024
@oleibman oleibman removed the stale label Jun 23, 2024
oleibman added a commit to oleibman/PhpSpreadsheet that referenced this issue Jun 23, 2024
This change is extracted from PR PHPOffice#2787 by @MarkBaker. That change mostly deals with array functions, and that part will be superseded by PR PHPOffice#3962. However, this part of 2787 is not included in 3962.

Fix PHPOffice#1036 (closed as stale in 2019 and just reopened). Excel spreadsheets can have either of 2 base dates, 1900 or 1904, and the numeric value of any date cells will vary depending on which base date is in use. PhpSpreadsheet has, till now, handled that as a static property of Shared/Date. This does not work well if two spreadsheets with different base dates are open simultaneously. The code is changed to store the base date as a property of the spreadsheet when an Xls/Xlsx spreadsheet is loaded, and use that property when saving an Xls/Xlsx spreadsheet. Any call to `getCalculatedValue` or `getFormattedValue` will temporarily set the Shared/Date value to that of the spreadsheet, and restore it at completion. In order to avoid a BC break, the Xls and Xlsx readers will continue to populate the Shared/Date value as before.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants