Prabal864 opened a new pull request, #6718: URL: https://github.com/apache/hive/pull/6718
### What changes were proposed in this pull request? `GenericUDFAddMonths`'s `@Description` Javadoc annotation documents the default output format and its example using the uppercase pattern `YYYY-MM-dd` (and `YYYY-MM-dd HH:mm:ss`). In Java's `SimpleDateFormat`, uppercase `Y` means the ISO *week-based* year, not the calendar year — it's a different field from lowercase `y`. The actual default formatter used by the code (`DateUtils.getDateFormat()`) correctly uses lowercase `"yyyy-MM-dd"`; only the documentation string was wrong. This PR corrects both occurrences in the `@Description` annotation from `YYYY` to `yyyy`, matching what the code actually does, and also normalizes the same pattern in `TestGenericUDFAddMonths`'s fixture constants (`fmtTextWithTime`, `fmtTextWithTimeAndms`, `fmtTextWithoutTime`, `fmtTextInvalid`), which perpetuated the same wrong-case convention. None of the existing assertions in that test use output dates within the ISO week-year boundary window (late December / early January), so this doesn't change any expected test result — it only removes the same latent risk from the test suite that the doc fix removes from user-facing docs. ### Why are the changes needed? A user who follows the documented example and passes a custom `output_date_format` containing `YYYY` (as literally shown in Hive's own docs) gets silently wrong output near year boundaries, because `SimpleDateFormat` interprets `YYYY` as the ISO week-year rather than the calendar year. This is exactly what was reported in HIVE-28117: `add_months(dt, -2, 'YYYY-MM')` on `2024-02-29` returned `2024-12` instead of `2023-12`, because Dec 29-31 dates can fall in a different ISO week-year than their calendar year. The underlying date arithmetic in `GenericUDFAddMonths` (`Calendar`-based month addition) is correct and unaffected — the bug is entirely that Hive's own documentation teaches users to use the wrong format pattern for calendar-year output. ### Does this PR introduce _any_ user-facing change? Yes, but only to documentation: `DESCRIBE FUNCTION EXTENDED add_months` now shows the correct `yyyy-MM-dd` pattern instead of the misleading `YYYY-MM-dd`. No query-execution behavior changes. ### How was this patch tested? This is a documentation-string-only change (a Java string literal inside an existing annotation), so no new test was added. No existing test asserts the `@Description` text itself. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
