[
https://issues.apache.org/jira/browse/FLUME-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172603#comment-15172603
]
Tristan Stevens commented on FLUME-2889:
----------------------------------------
Hi [~roshan_naik], LGTM - sorry for the delay.
In answer to your questions:
1) Yes, there could be some unexpected behaviour when a 29 Feb is observed in a
non-leap year.
2) The timestamp written will be in epoch format, so I think it will always be
valid. The way the timestamp is created (create a year-2000 timestamp and then
apply the new year) avoids any chances of an unhandled exception (I think). My
customer is doing HDFS bucketting based on the extracted timestamp, but:
3) I couldn't recreate an example where the behaviour with the old code was
undesirable - hence I wrote the additional unit tests. Certainly subtraction
through a 29th February seemed to work okay, the only un-certain behaviour is
when a 29 Feb occurs in a non-leap year. In which case setting to 28th February
seems reasonable IMHO.
So not sure that there was a bug to start with!
But I'm happy for it to be committed.
> Fixes to DateTime computations
> -------------------------------
>
> Key: FLUME-2889
> URL: https://issues.apache.org/jira/browse/FLUME-2889
> Project: Flume
> Issue Type: Bug
> Affects Versions: v1.6.0
> Reporter: Roshan Naik
> Assignee: Roshan Naik
> Fix For: v1.7.0
>
> Attachments: FLUME-2889-2.patch, FLUME-2889.3.patch, FLUME-2889.patch
>
>
> date.withYear(year+1) can lead to incorrect date calculations .. for example
> if the date is Feb 29th. need to use date.plusYears(1) instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
