This PR builds on @yookoala's excellent work by making some additional changes to improve backwards compatibility while aiming to keep the code maintainable.
All readable date formats now use a constant to define which pattern to use, and these constants (nearly) mirror the exact ones used by the IntlDateFormatter class. This decouples the logic of which type of date to use from the pattern itself.
The constants for IntlDateFormatter have been extended to add _NO_YEAR options, which matches many of the use cases for date formatting.
Fallback date formats can now be handled internally, because the intent of the format is communicated through the constant. These can then be removed in the future when a fallback is no longer needed.
Rather than introducing a new method name, the original method has been refactored, but is still backwards compatible if passed a non-integer value, falling back to a default date format.
If the IntlDatePatternGenerator is present, then the date formats will be constructed on setup for the chosen locale, creating better localised date formatting.
Motivation and Context
Moving the implementation of date patterns/formats internally and using an enumerated constant should make the code more readable and maintainable long-term. Anything using a date class will no longer rely on concrete date patterns, enabling the Format class to handle the patterns internally, and apply fallbacks as necessary.
This PR builds on @yookoala's excellent work by making some additional changes to improve backwards compatibility while aiming to keep the code maintainable.
Motivation and Context Moving the implementation of date patterns/formats internally and using an enumerated constant should make the code more readable and maintainable long-term. Anything using a date class will no longer rely on concrete date patterns, enabling the Format class to handle the patterns internally, and apply fallbacks as necessary.
How Has This Been Tested? Locally