[ROCKETMQ-111] fix possible MQClientException when query message before today

[scaat]

JIRA:https://issues.apache.org/jira/browse/ROCKETMQ-111
Using "cal.set(Calendar.HOUR,0);" when query message before today which may result in :
"org.apache.rocketmq.client.exception.MQClientException: CODE: 208 DESC: query message by key finished, but no message. "
"HOUR" is used for the 12-hour clock.This will cause the start time of the query message to be greater than the creation time of the message.
Implemenations:
Using "HOUR_OF_DAY" instead of "HOUR"."HOUR_OF_DAY" is used for the 24-hour clock.
Is that so?@Jaskey @zhouxinyu

[Jaskey]

Hi @yilingfeng , please modify your PR subject and mention your jira address in the description, you can follow this PR. #5

[zhouxinyu]

LGTM, thanks @yilingfeng , and please relate the JIRA issue.

Please @vongosling @lizhanhui help review.

[coveralls]

Coverage increased (+0.06%) to 31.58% when pulling 45647c0 on yilingfeng:master into 573b22c on apache:master.

[lizhanhui]

Good catch.
Looks good to me.

[vongosling]

+1

[Jaskey]

From java doc, 0 of HOUR is representing noon or midnight.

So this problem exists if we call the methods after 12:Am, the actualy hour will becomes 12 rather than 0, which may result in problems.

Good catch and nice job.

FYI:

you could try with different system clock, which will give you a different result.

    Calendar cal = Calendar.getInstance();
    cal.set(Calendar.DAY_OF_MONTH, 1);
    cal.set(Calendar.HOUR, 0);
    cal.set(Calendar.MINUTE, 0);
    cal.set(Calendar.SECOND, 0);
    cal.set(Calendar.MILLISECOND, 0);

    System.out.println(new Date(cal.getTimeInMillis()));
    System.out.println(cal.get(Calendar.AM_PM));

[shroman]

Good catch. I would add unit tests though ;)

[scaat]

Thank you for your detailed and clear explanation. It was very helpful and understandable. @Jaskey

[zhouxinyu]

@shroman , this PR will be merged soon, looking forward to your unit tests..😀😀😀😀

[shroman]

@zhouxinyu Probably you misunderstood what I meant :) -- this PR needs unit tests. I think it's the responsibility of the person who submitted PR to create them, whenever possible, since it reflects his/her intentions.
@yilingfeng Can you please add unit tests?

[scaat]

Ok,I've added a unit test. @lizhanhui @shroman

[vongosling]

thanks @yilingfeng . Consider this PR has been merged, we will commit your unit-test in another commit. @shroman I have a same understand as @zhouxinyu about your unit-test said :-)

[shroman]

@vongosling I meant "If I were you, I would ..." :) Anyway, I don't see why this pr can be merged without a unit test that can be easily written. I think we have to accept PRs with tests, except for the cases when they cannot be implemented.
Ok, then let's close this pr? and tests can be submitted in another one.

@yilingfeng I had a quick look, and here is what I think.
Better name the file MessageClientIDSetterTest.java and have tests for getNearlyTimeFromID() etc. instead of implementing another method and testing it in your unit test class.

[scaat]

Sorry, I’ve modified the unit tests. @shroman

[shroman]

@yilingfeng Great 👍 But let's have a new PR for that, as @vongosling commented above (if I understood it correctly)?

[scaat]

What does it mean? @vongosling @shroman

[zhouxinyu]

Hi @yilingfeng @shroman , there is no need to open a new PR, the new commit will be merged to develop branch directly.

[shroman]

@zhouxinyu Thanks for clarifying it! ;)
If we don't want to test the private method too, I am ok with the tests now to be merged.

[coveralls]

Changes Unknown when pulling e91b850 on yilingfeng:master into ** on apache:master**.

[coveralls]

Changes Unknown when pulling e91b850 on yilingfeng:master into ** on apache:master**.

[coveralls]

Changes Unknown when pulling e91b850 on yilingfeng:master into ** on apache:master**.

[vongosling]

@yilingfeng Could you close this PR. We have merged this pull request 29 days ago.