It encapsulates some date operations like sum. The result will be the
calculated date when calling the nextDateByInterval method, given the
date, periodicity, and skipInterval parameters.
For example, given a date of 2019-12-31, monthly periodicity, and skip
interval 0, the results will be 2020-01-31. Also, if the skip interval
is 1, the result is 2020-02-29. This is because the next date will add
another month to the current range.
All these strategies encapsulate how the Carbon library adds the
interval to the current date.
Monthly, Quarterly, Half-Yearly, and Yearly explicitly use the
overflow control to guarantee the end of the next month or year
adequately.
It is responsible for calculating and manipulating Dates in financial
organization is a very important feature, and requires significant
coverage.
The first test case is just to create an understanding of how it
works.
Currently the php function `number_format` is used to format currencies.
This is problematic as we have to figure out different things for
different currencies ourselves. These formats are determined based on
the libc's locale functions.
The issue arises where an OS doesn't have the proper locales installed,
or, in some cases, it's not supported (see below on multiple issues).
This addresses this issue by using the php-intl extensions to format the
numbers based on the locale. The extension is already a requirement in
`composer.json`. The solution does not rely on `LC_MONETARY` from the
underlying libc (which in Alpine Linux's case, which uses musl, is not
supported as of yet).
List of issues that are related and would potentially be fixed using
this PR:
- #2298
- #2946
- #3070
- #3306
- #3519
