I hadn't. It appears that might work. Technically speaking, I think using the commas is not a concatenation, although practically speaking the they might yield the same results. I would guess that commas might be more efficient (you just need to send each string to stdout, whereas with periods you would have to concatenate first before sending the string). Also worth noting - V2 did not make this change but V3 does. At any rate, thank you for the suggestion. I would still be interested in knowing if there is a rule that controls this behavior.

Support question

My code looks this:

echo "blahblahblah",
    "yaddayaddayadda",
    "etcetcetc";

Php-cs-fixer wants to change it to:

echo "blahblahblah",
"yaddayaddayadda",
"etcetcetc";

I cannot figure out what rule is causing this change. Is there a way to stop it from happening?

Scrutinizer

The sun rises in the east, and Scrutinizer issues more false positives.

It isn't a feature of Excel that I've made any use of, but PR #3476 added better Theme support for colors, and it is relatively easy to add Theme support for Fonts on top of that.

Excel assigns two theme fonts to its spreadsheets, one for Headings (major), and one for Body (minor). If the body theme is Calibri, when you choose a font for a cell in Excel, you can choose 'Calibri (Body)' from the Theme Fonts section at the top of the Font dropdown, or 'Calibri' from the 'All Fonts' section. If you choose the former, the cell will be automatically restyled if you change the Theme Fonts (via Page Layout, Themes, Fonts). The relationship to the theme fonts is recorded in the XML via a scheme tag (descending from font) whose val attribute can be either major or minor. Accordingly, this PR, in addition to defining the Theme Font properties, adds a scheme property, with getter and setter, to Style/Font.

The main benefit of this PR is that you can now load and save a spreadsheet preserving the connections to the Theme Fonts, without having to take any additional action.

A secondary benefit arises from the following difference. Empty cells in Excel will use the spreadsheet's default font name when they are filled in; but, in Google Sheets, they will use the Theme Minor Font name. By setting the scheme property in the default style, the resulting spreadsheet will behave the same in both Excel and Google.

I will note that Excel's font themes specify a Latin font, an East Asian font, a Complex Scripts font, and a set of font substitutions for various languages. PhpSpreadsheet will preserve all of these, and allow them to be changed. However, although it is easy to imagine how the non-Latin options might work, I have not yet been able to come up with an example where Excel uses any of them. In particular, if I use a theme font which does not support language X, and I use Language X in a cell bound to the theme, Excel will use a substitution font which does support it, but the font which it uses does not seem to be chosen from the alternatives supplied in the theme.

This is:

• [ ] a bugfix
• [x] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [x] New unit tests have been added
• [x] Code style is respected
• [x] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [x] Documentation is updated as necessary

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate). If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

Include previous exception in \PhpOffice\PhpSpreadsheet\Cell\Cell::getCalculatedValue

When loading a file and accessing cells outside a filter range, we still check for shared formulae that may need to be used inside the filter range; so we test for the cell's f attribute. However, in some cases this attribute isn't set and we need to check for the presence of an f child element with a shared attribute

Catch Up Change Log (#3475)

Some changes missing since release 28.

Scouting improvement: move the Shared Formula data to an object in an instance array, rather than using a simple nested array. This should be better for memory usage; and when we can apply readonly to object properties, then we can make the properties readonly public, eliminate the getters in the SharedFormula class

ChangeLog

Merge branch 'master' into Issue-3473_Shared-Formula-Chunked-Read-no-attribute-set

Merge pull request #3474 from PHPOffice/Issue-3473_Shared-Formula-Chunked-Read-no-attribute-set

Shared Formulae outside the filter range when reading with a filter are not always being identified

Inline documentation updates

Update to Change Log

Duration NumberFormat Wizard

Add defaults for Date and Time NumberFormat Wizards

Merge pull request #3481 from PHPOffice/NumberFormat-Wizard-DateTime-Defaults

Add defaults for Date and Time NumberFormat Wizards

Merge branch 'master' into NumberFormat-Wizard-Duration

Merge pull request #3479 from PHPOffice/NumberFormat-Wizard-Duration

Duration NumberFormat Wizard

Merge branch 'master' into patch-1

Merge pull request #3329 from mpdude/patch-1

Include previous exception in \PhpOffice\PhpSpreadsheet\Cell\Cell::getCalculatedValue()

WIP Handle REF Error as Part of Range (#3467)

Fix #3453. User sets a valid formula (e.g. =SUM(Sheet2!B1:Sheet2!B3)), and then does something to invalidate the formula (e.g. delete Sheet2). Excel changes the formula to SUM(#REF!:#REF!) when the spreadsheet is saved; apparently someone thought this was a good idea. But PhpSpreadsheet (a) used to throw an Exception when it evaluated the formula, and (b) now gives a result of 0 when evaluating the formula. Neither is ideal. It would be better to propagate the #REF! error.

It is likely that more tests are needed, which is why I will keep this in draft status for a bit.

update instructions for migration from phpexcel (#3483)

Font/Effects/Theme Support for Chart Data Labels and Axis (#3476)

• Font and Effects Support for Chart Data Labels and Axis

Addresses some remaining issues with 32readwriteLineChart5 (see issue #1797). Font size is covered. So are effects, although the results are a bit odd. For the new spreadsheet 32readwriteLineChart6, the Axis labels have a yellow-ish glow, but reading and writing the spreadsheet in PhpSpreadsheet gives them a purple-ish glow. Nevertheless, the new test shows that the output file uses schemeClr accent4, as does the input file. So the effect is handled correctly, but it seems there is likely to be a difference between theme colors (Writer/Xlsx/Theme appears to write hard-coded color schemes, and, in any case, Reader/Xlsx does not appear to handle schemeClr). Fixing that will be a great deal more difficult, with a large chance of regression, and will need to happen in a separate PR (one that I am not currently investigating, but I will open a new issue). Effects using srgbClr (and probably sysclr) should be okay.

• Better Theme Support

When reading Xlsx, the theme colors will now also be used for writing. This means that a file can be loaded and saved and its chart colors will now be preserved. If the spreadsheet is created new, Excel 2007-2010 colors are used. The writer is currently hard-coded to use them, so this avoids making this a breaking change. The theme colors can be explicitly changed if desired, and Excel 2013+ colors can be introduced very easily.

$spreadsheet->getTheme()
    ->setThemeColorName(Theme::COLOR_SCHEME_2013_PLUS_NAME);

Likewise, if the old behavior of changing to the 2007-2010 scheme rather than using the input values is desired, that is easy to achieve after the load has taken place.

$spreadsheet->getTheme()
    ->setThemeColorName(Theme::COLOR_SCHEME_2007_2010_NAME);

The new Theme class introduced by this change can easily be extended to include Fonts and Effects. Unlike Colors, I am unsure what the practical effects of changing those to, say, the 2013+ defaults would be.

• Scrutinizer

Use an alias in a use statement.

• Update Change Log

Due to potential behavior change.

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)

What is the expected behavior?

Theme/scheme colors should be read as part of Xlsx Reader, and reproduced by Xlsx Writer.

What is the current behavior?

Reader appears to ignore scheme colors. Writer appears to write theme file with hard-coded colors. As a result, the input and output files may differ in their coloring when scheme colors are used. This is especially noticeable in some charts (see PR #3476); I suspect, but am not certain, that other situations might also be affected.

What are the steps to reproduce?

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

After the PR identified above is merged, this behavior is demonstrated by sample 32readwriteLineChart6.

What features do you think are causing the issue

• [x] Reader
• [x] Writer
• [ ] Styles
• [ ] Data Validations
• [ ] Formula Calculations
• [ ] Charts
• [ ] AutoFilter
• [ ] Form Elements

Does an issue affect all spreadsheet file formats? If not, which formats are affected?

This is probably just a problem for Xlsx.

Which versions of PhpSpreadsheet and PHP are affected?

All.

Font/Effects/Theme Support for Chart Data Labels and Axis (#3476)

• Font and Effects Support for Chart Data Labels and Axis

Addresses some remaining issues with 32readwriteLineChart5 (see issue #1797). Font size is covered. So are effects, although the results are a bit odd. For the new spreadsheet 32readwriteLineChart6, the Axis labels have a yellow-ish glow, but reading and writing the spreadsheet in PhpSpreadsheet gives them a purple-ish glow. Nevertheless, the new test shows that the output file uses schemeClr accent4, as does the input file. So the effect is handled correctly, but it seems there is likely to be a difference between theme colors (Writer/Xlsx/Theme appears to write hard-coded color schemes, and, in any case, Reader/Xlsx does not appear to handle schemeClr). Fixing that will be a great deal more difficult, with a large chance of regression, and will need to happen in a separate PR (one that I am not currently investigating, but I will open a new issue). Effects using srgbClr (and probably sysclr) should be okay.

• Better Theme Support

When reading Xlsx, the theme colors will now also be used for writing. This means that a file can be loaded and saved and its chart colors will now be preserved. If the spreadsheet is created new, Excel 2007-2010 colors are used. The writer is currently hard-coded to use them, so this avoids making this a breaking change. The theme colors can be explicitly changed if desired, and Excel 2013+ colors can be introduced very easily.

$spreadsheet->getTheme()
    ->setThemeColorName(Theme::COLOR_SCHEME_2013_PLUS_NAME);

Likewise, if the old behavior of changing to the 2007-2010 scheme rather than using the input values is desired, that is easy to achieve after the load has taken place.

$spreadsheet->getTheme()
    ->setThemeColorName(Theme::COLOR_SCHEME_2007_2010_NAME);

The new Theme class introduced by this change can easily be extended to include Fonts and Effects. Unlike Colors, I am unsure what the practical effects of changing those to, say, the 2013+ defaults would be.

• Scrutinizer

Use an alias in a use statement.

• Update Change Log

Due to potential behavior change.

Addresses some remaining issues with 32readwriteLineChart5 (see issue #1797). Font size is covered. So are effects, although the results are a bit odd. For the new spreadsheet 32readwriteLineChart6, the Axis labels have a yellow-ish glow, but reading and writing the spreadsheet in PhpSpreadsheet gives them a purple-ish glow. Nevertheless, the new test shows that the output file uses schemeClr accent4, as does the input file. So the effect is handled correctly, but it seems there is likely to be a difference between theme colors (Writer/Xlsx/Theme appears to write hard-coded color schemes). Fixing that will be a great deal more difficult, with a large chance of regression, and will need to happen in a separate PR (one that I am not currently investigating, but I will open a new issue). Effects using srgbClr (and probably sysClr) should be okay.

Fix #3477. It turns out the color schemes are not so difficult to support as I had feared, and it probably applies only or mostly to charts. When reading Xlsx, the theme colors will now also be used for writing. This means that a file can be loaded and saved and its chart colors will now be preserved. If the spreadsheet is created new, Excel 2007-2010 colors are used. The writer is currently hard-coded to use them, so this avoids making this a breaking change. The theme colors can be explicitly changed if desired, and Excel 2013+ colors can be introduced very easily.

$spreadsheet->getTheme()
    ->setThemeColorName(Theme::COLOR_SCHEME_2013_PLUS_NAME);

Likewise, if the old behavior of changing to the 2007-2010 scheme rather than using the input values is desired, that is easy to achieve after the load has taken place.

$spreadsheet->getTheme()
    ->setThemeColorName(Theme::COLOR_SCHEME_2007_2010_NAME);

The new Theme class introduced by this change can easily be extended to include Fonts and Effects. Unlike Colors, I am unsure what the practical effects of changing those to, say, the 2013+ defaults would be.

This is:

• [x] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [x] Changes are covered by existing unit tests
  • [x] New unit tests have been added
• [x] Code style is respected
• [x] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate). If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

Include previous exception in \PhpOffice\PhpSpreadsheet\Cell\Cell::getCalculatedValue

Duration NumberFormat Wizard

Merge branch 'master' into NumberFormat-Wizard-Duration

Merge pull request #3479 from PHPOffice/NumberFormat-Wizard-Duration

Duration NumberFormat Wizard

Merge branch 'master' into patch-1

Merge pull request #3329 from mpdude/patch-1

Include previous exception in \PhpOffice\PhpSpreadsheet\Cell\Cell::getCalculatedValue()

WIP Handle REF Error as Part of Range (#3467)

Fix #3453. User sets a valid formula (e.g. =SUM(Sheet2!B1:Sheet2!B3)), and then does something to invalidate the formula (e.g. delete Sheet2). Excel changes the formula to SUM(#REF!:#REF!) when the spreadsheet is saved; apparently someone thought this was a good idea. But PhpSpreadsheet (a) used to throw an Exception when it evaluated the formula, and (b) now gives a result of 0 when evaluating the formula. Neither is ideal. It would be better to propagate the #REF! error.

It is likely that more tests are needed, which is why I will keep this in draft status for a bit.

update instructions for migration from phpexcel (#3483)

Merge branch 'master' into labelfont

PHP Fatal error: Uncaught Error: Class 'PhpOffice\PhpSpreadsheet\Calculation\Engine\CyclicReferenceStack' not found in /var/www/html/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:2763\nStack trace:\n#0 /var/www/html/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Spreadsheet.php(476): PhpOffice\PhpSpreadsheet\Calculation\Calculation->__construct()\n#1 /var/www/html/connect_ssh/phpexcel.php(7): PhpOffice\PhpSpreadsheet\Spreadsheet->__construct()\n#2 {main}\n thrown in /var/www/html/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php on line 2763, referer: http://***********/connect_ssh/

this my code :

No update in 18 months, closing.

I have implemented this library for a client and we are in need of generating multiple page PDF by number of sheets in a spreadsheet. I can see it is not implemented at this point. I can however, for the time being, do some work around for this.

Closing, no update in 11 months, no reason to think that the suggested code will not work.

No update in 9 months, closing.

In the graph there is a property called setAxisOptionsProperties, we are not able to manage that line according to the bars. We want to control the vertical line and want to show it accordingly to us.

Thank you for your contribution.

update instructions for migration from phpexcel (#3483)

This is:

• [ ] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests
• [x] a docs change

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [ ] New unit tests have been added
• [ ] Code style is respected
• [ ] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [x] Documentation is updated as necessary

Why this change is needed?

Replaces an outdated link and adds a missing package to be installed

Include previous exception in \PhpOffice\PhpSpreadsheet\Cell\Cell::getCalculatedValue

Duration NumberFormat Wizard

Merge branch 'master' into NumberFormat-Wizard-Duration

Merge pull request #3479 from PHPOffice/NumberFormat-Wizard-Duration

Duration NumberFormat Wizard

Merge branch 'master' into patch-1

Merge pull request #3329 from mpdude/patch-1

Include previous exception in \PhpOffice\PhpSpreadsheet\Cell\Cell::getCalculatedValue()

WIP Handle REF Error as Part of Range (#3467)

Fix #3453. User sets a valid formula (e.g. =SUM(Sheet2!B1:Sheet2!B3)), and then does something to invalidate the formula (e.g. delete Sheet2). Excel changes the formula to SUM(#REF!:#REF!) when the spreadsheet is saved; apparently someone thought this was a good idea. But PhpSpreadsheet (a) used to throw an Exception when it evaluated the formula, and (b) now gives a result of 0 when evaluating the formula. Neither is ideal. It would be better to propagate the #REF! error.

It is likely that more tests are needed, which is why I will keep this in draft status for a bit.

Merge branch 'master' into patch-1

This is:

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

What is the expected behavior?

Prior to version 1.26.0 calculating the value of a formula that contains a reference error (eg. =SUM(B1:#REF!)) would result in a

[PhpOffice\PhpSpreadsheet\Calculation\Exception]               
  Worksheet!B4 -> Cell coordinate can not be zero-length string

What is the current behavior?

From 1.26.0 until now (1.28.0) the result is 0 instead of an exception.

What are the steps to reproduce?

<?php

require __DIR__ . '/vendor/autoload.php';

$spreadsheet = new Spreadsheet();
$worksheet = $spreadsheet->getActiveSheet();

$worksheet->setCellValue('B4', '=SUM(B1:#REF!)');

// Throws Calculation\Exception when < 1.26.0
$value = $worksheet->getCell('B4')->getCalculatedValue();

// Returns 0 in 1.26.0+
\var_dump($value);

What features do you think are causing the issue

• [ ] Reader
• [ ] Writer
• [ ] Styles
• [ ] Data Validations
• [x] Formula Calculations
• [ ] Charts
• [ ] AutoFilter
• [ ] Form Elements

Does an issue affect all spreadsheet file formats? If not, which formats are affected?

I have tested with .xlsx, don't see why it wouldn't affect all other formats.

Which versions of PhpSpreadsheet and PHP are affected?

PHP 8.1.16 PHPSpreadsheet 1.26.0+ (until at least 1.28.0)

WIP Handle REF Error as Part of Range (#3467)

Fix #3453. User sets a valid formula (e.g. =SUM(Sheet2!B1:Sheet2!B3)), and then does something to invalidate the formula (e.g. delete Sheet2). Excel changes the formula to SUM(#REF!:#REF!) when the spreadsheet is saved; apparently someone thought this was a good idea. But PhpSpreadsheet (a) used to throw an Exception when it evaluated the formula, and (b) now gives a result of 0 when evaluating the formula. Neither is ideal. It would be better to propagate the #REF! error.

It is likely that more tests are needed, which is why I will keep this in draft status for a bit.

Fix #3453. User sets a valid formula (e.g. =SUM(Sheet2!B1:Sheet2!B3)), and then does something to invalidate the formula (e.g. delete Sheet2). Excel changes the formula to SUM(#REF!:#REF!) when the spreadsheet is saved; apparently someone thought this was a good idea. But PhpSpreadsheet (a) used to throw an Exception when it evaluated the formula, and (b) now gives a result of 0 when evaluating the formula. Neither is ideal. It would be better to propagate the #REF! error.

It is likely that more tests are needed, which is why I will keep this in draft status for a bit.

This is:

• [x] a bugfix
• [ ] a new feature
• [ ] refactoring
• [ ] additional unit tests

Checklist:

• [ ] Changes are covered by unit tests
  • [ ] Changes are covered by existing unit tests
  • [x] New unit tests have been added
• [x] Code style is respected
• [x] Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• [ ] CHANGELOG.md contains a short summary of the change and a link to the pull request if applicable
• [ ] Documentation is updated as necessary

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate). If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

Include previous exception in \PhpOffice\PhpSpreadsheet\Cell\Cell::getCalculatedValue

Refactor unit tests to ensure that assertions are in the actual test, and not in an abstract class; and that setup/teardown are in the test and not an abstract. This means that assertions and setup/teardown are always in the file when reviewing PRs. Also enforce more rigorous Excel Function implementation by testing the underlying implementation, call via the Calc Engine, and execution from in a worksheet. Separate out unhappy path (exception) checks into a separate test, so that a single test isn't made overcomplex checking for every potentiality.

Scrutinizer may dislike variadics, for variable number of arguments of mixed type; but tough. It's 100% valid PHP, accepted by phpstan, and makes life a lot easier.

Initial work here covers all the database and datetime unit tests for Excel function implementations.

Scrutinizer really sucks!!!

Stop a few of scrutinizers complaints about 100% valid use of PHP variadics. Hopefully, this issue will cease to be an issue when we can specify mixed datatype for variadic arguments in the tests

Additional edge-case tests

Extended unit tests for Engineering functions

Merge branch 'master' into UnitTests_Refactoring-Database-and-DateTime

Merge pull request #3448 from PHPOffice/UnitTests_Refactoring-Database-and-DateTime

Refactor unit tests to ensure that assertions and setup/teardown are in the actual test for ease of review

Initial work on Date, Time and DateTime NumberFormat Wizards

Refinements to Date, Time and DateTime NumberFormat Wizards

Escape single characters in Date, Time and DateTime NumberFormat Wizards

Issue 3461 - Establish boundary for function prefix regexp to prevent NETWORKDAYS being picked up by DAYS

Merge pull request #3463 from PHPOffice/Issue-3461_Xlsx-Writer-FunctionPrefix-Regexp

Establish boundary for function prefix regexp to prevent over-aggressive prefixing

Merge branch 'master' into NumberFormat-Wizards-Date-Time-Duration

Merge pull request #3458 from PHPOffice/NumberFormat-Wizards-Date-Time-Duration

Initial work on Date, Time and DateTime NumberFormat Wizards

Update to Readd Me

Update to Read Me

Specify data type in html tags using attributes (#3445)

• Specify data type in html tags using attributes #3444

• Set data types using attributes in flushCell function and add some unit tests

• Check TYPE_INLINE in flushCell and some changes in test cases

Fix incorrect font color read from xlsx (#3465)

Place the read font color after setting the styles

Use NBSP in Accounting Wizard, and as an option for Date/Time Wizards

Merge branch 'master' into NumberFormat-Wizards_Non-breaking-space

Xls Reader Conditional Styles (#3400)

The code currently allocates the style object as a non-conditional style, leading to corruption when the spreadsheet is written out.

That being said, Font Color is the only Conditional Formatting I have gotten to work for Xls for read or write. Use of other styles will essentially continue to be ignored, but will at least no longer result in corrupt spreadsheets.

Allow use of # and 0 digit placeholders in fraction masks

Merge pull request #3401 from PHPOffice/NumberFormatter-Improved-Fractions

Allow use of # and 0 digit placeholders in fraction masks

Update Change Log for release

Prepare Change Log for next release

Issue 3368 - Absolute References in Cell Formulae should always be updated when inserting/deleting rows/columns

Issue 3368 - Absolute References in Defined Names should always be updated when inserting/deleting rows/columns

Note: If we delete the entire range that is referenced by a Named Formula, MS Excel sets the value to #REF! PhpSpreadsheet still only does a basic adjustment, so the Named Formula will still reference Cells.

Merge pull request #3402 from PHPOffice/Issue-3368_Absolute-Cell-References-on-Insert-Delete

Absolute References in Cell Formulae should always be updated when inserting/deleting rows/columns

Documentation updates

Merge pull request #3407 from PHPOffice/Fix-docs-typo

Documentation updates

Update Change log

Modify Date/Time check in the NumberFormatter so that masks with a decimal/fractional time aren't misinterpreted as number masks, while still ensuring that durations are interpreted as date/time masks, and locale currency masks are still treated as numbers

A date/time with a decimal time shouldn't have a digit placeholder before the decimal point, only after

Merge pull request #3413 from PHPOffice/Issue-3412_Date-Format-with_decimals-interpreted-as-Number-Format

Modify Date/Time check in the NumberFormatter for decimal/fractional times

Bump phpunit/phpunit from 9.6.3 to 9.6.4 (#3418)

Bumps phpunit/phpunit from 9.6.3 to 9.6.4.

• Release notes
• Changelog
• Commits

updated-dependencies:

• dependency-name: phpunit/phpunit dependency-type: direct:development update-type: version-update:semver-patch ...

Signed-off-by: dependabot[bot] support@github.com Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bump mitoteam/jpgraph from 10.2.4 to 10.2.5 (#3419)

Bumps mitoteam/jpgraph from 10.2.4 to 10.2.5.

• Release notes
• Commits

updated-dependencies:

• dependency-name: mitoteam/jpgraph dependency-type: direct:development update-type: version-update:semver-patch ...

Signed-off-by: dependabot[bot] support@github.com Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bump friendsofphp/php-cs-fixer from 3.14.3 to 3.14.4 (#3422)

Bumps friendsofphp/php-cs-fixer from 3.14.3 to 3.14.4.

• Release notes
• Changelog
• Commits

updated-dependencies:

• dependency-name: friendsofphp/php-cs-fixer dependency-type: direct:development update-type: version-update:semver-patch ...

Signed-off-by: dependabot[bot] support@github.com Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bump squizlabs/php_codesniffer from 3.7.1 to 3.7.2 (#3420)

Bumps squizlabs/php_codesniffer from 3.7.1 to 3.7.2.

• Release notes
• Commits

updated-dependencies:

• dependency-name: squizlabs/php_codesniffer dependency-type: direct:development update-type: version-update:semver-patch ...

Signed-off-by: dependabot[bot] support@github.com Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Stricter typing for ReferenceHelper methods; and performance improvements for cell sorting in ReferenceHelper callbacks

Scrutinizer can only be appeased by adding extra code to pre-define variables that don't need to be pre-defined, and that makes for additional code overhead in a routine that needs to be as performant as possible; so "scrutinizer be damned!"

PhpStan 10.3 (#3425)

Address the usual collection of new messages. This will supersede PR #3417 and PR #3421.

Merge branch 'master' into ReferenceHelper_Stricter-TypingCasting