Re:Intl
by lifthrasiir on Wednesday June 02, 2021 @06:16AM
(#27366932)
I should clarify that my dislike of YearMonth and ilks is for standard types without any localization [1] or non-Gregorian support. They do crop up from time to time but you have a very straightforward representation of YearMonth in any reasonable language: a pair of (year, month), essentially interpreted as a mixed-radix number. Date and general date-time components are not that simple (thanks to the calendar system itself, leap seconds and time zones) and deserves separate types.
[1] I firmly believe that the localization support is too large for standard libraries. In particular, that "localization support" usually means that you have a ripoff version of CLDR & ICU interface and no equivalent to something like gettext, essential to any actual localization task.
- data processing and graphing: a lot of data is collected on a monthly basis and represents the aggregate for that month (like monthly energy use). Naively storing it as a full date and ignoring the day means that you now have a compatibility issue with other data, collected monthly, that isn't aggregate (like the height of a tree) - "[THING] of the month": something is chosen by a community poll or admin or however else to be highlighted for/of that month You need something to use as a key for it and a YearMonth captures the requirements perfectly. Especially when you then have to display a localised title above it, having it be a distinct class and not just a full date will save you a lot of trouble. - same as above, but a more business-y use case: various monthly reports. Usually created in the next month, you need a way to represent which month it's "for"