HIVE-28117: Fix misleading YYYY date pattern in add_months() documentation - #6718
Open
Prabal864 wants to merge 1 commit into
Open
HIVE-28117: Fix misleading YYYY date pattern in add_months() documentation#6718Prabal864 wants to merge 1 commit into
Prabal864 wants to merge 1 commit into
Conversation
…ation GenericUDFAddMonths's @description Javadoc documented the default output format and its example using the uppercase pattern YYYY-MM-dd. In Java's SimpleDateFormat, uppercase Y means the ISO week-based year, not the calendar year - a different field from lowercase y. The actual default formatter used by the code (DateUtils.getDateFormat()) already correctly uses lowercase "yyyy-MM-dd"; only the documentation string was wrong. 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, exactly as reported in HIVE-28117: add_months(dt, -2, 'YYYY-MM') on 2024-02-29 returned '2024-12' instead of '2023-12'. Also normalizes the same pattern in TestGenericUDFAddMonths's fixture constants, which perpetuated the same wrong-case convention. No existing assertion uses an output date within the ISO week-year boundary window, so this doesn't change any expected test result. No runtime behavior changes - this is a documentation-string-only fix.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
GenericUDFAddMonths's@DescriptionJavadoc annotation documents the default output format and its example using the uppercase patternYYYY-MM-dd(andYYYY-MM-dd HH:mm:ss). In Java'sSimpleDateFormat, uppercaseYmeans the ISO week-based year, not the calendar year — it's a different field from lowercasey. 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
@Descriptionannotation fromYYYYtoyyyy, matching what the code actually does, and also normalizes the same pattern inTestGenericUDFAddMonths'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_formatcontainingYYYY(as literally shown in Hive's own docs) gets silently wrong output near year boundaries, becauseSimpleDateFormatinterpretsYYYYas the ISO week-year rather than the calendar year. This is exactly what was reported in HIVE-28117:add_months(dt, -2, 'YYYY-MM')on2024-02-29returned2024-12instead of2023-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_monthsnow shows the correctyyyy-MM-ddpattern instead of the misleadingYYYY-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
@Descriptiontext itself.