GitLogTest fails due to system time >= 2019

[fzdy1914]

The gitLog_sinceDateInFuture_noContent methoed fails at the latest master commit. [#316] Split RepoConfiguration into more classes (#425)

[yong24s]

Confirmed that the test fails and it is related to system time.

Preliminary findings on why this bug has slip through CI: While it is not depended on git version and system/platform, it is depended on system time. It can be verified that this test passed if system time is set to a date before 2019.

@eugenepeh @yamidark For confirmation and further investigation.

[yamidark]

Yes, verified this issue. Testing on my side, it seems giving an 'until' date year 1950 will give all commit result, meaning they may have ignored this since the date was too long ago (no idea why this suddenly occurred in 2019 though). Changing the date to be earlier, like 1970, will resolve this though.

[yamidark]

Also, since we are already resolving this, we should also extract this test out into a different method name gitLog_untilDateBeforeAnyCommit_noContent().

[yamidark]

@fzdy1914 Would you like open a PR to fix this?

[fzdy1914]

@yamidark One of my friends is fixing it now. So I will leave it to her.

[eugenepeh]

Just a passing by remark, seems like this is the same as Year 2038 problem. The time difference may have caused the 32-bit integer overflowed.

[yamidark]

Lowing the priority since we have added in a hotfix for this issue in #455

[dcshzj]

The issue is due to Git not being able to handle timestamps before Unix epoch. On any Git repository, the following command should not give you any results:

git log --until="1970-01-01T00:00:00UTC"

However, the following command will give you results (which was the original test case):

git log --until="1950-01-01T00:00:00UTC"

Interestingly, it gives you all commits up till the final commit of the previous year. For example, running this command in 2021 will give you commits until the last day of 2020. This was the cause of the test case breaking, because the testrepo-Alpha had commits only in 2018, and the test case was passing in 2018 because there were no commits in 2017 and before. Thus, it makes sense that the test started breaking in 2019, because it was already flawed.

On the other hand, the following command should give you all commits in the repository:

git log --since="1970-01-01T00:00:00UTC"

Likewise, the following command should give you the same results as above:

git log --since="1950-01-01T00:00:00UTC"

However, only commits performed since the start of the year are shown (i.e. all 2021 commits if you are running it in 2021). The same problem happens when the date 2100-01-01T00:00:00UTC is provided.

Hence, the output from git log is unexpected when dates earlier than the epoch is provided, or when the date is on or beyond 2100. RepoSense should thus be configured to automatically reset the dates provided by the user such that the earliest possible timestamp is 1970-01-01T00:00:00UTC and the latest possible timestamp is 2099-12-31T23:59:59UTC.

This task is trivial and suitable for first timers. It involves changing either ArgsParser.java or both the SinceDateArgumentType.java and UntilDateArgumentType.java files in the parser folder to limit the possible date ranges.

[litone01]

Hi @dcshzj As discussed in the previous MR (https://github.com/reposense/RepoSense/pull/1558), I am planning to take a more complicated first-timer issue, and this one seems nice! Can I do this? Thanks!

[dcshzj]

@litone01 Sure, please go ahead!

[litone01]

@dcshzj Hi, I have investigated the issue and the suggested direction to solve the issue. After premilinary investigation, I think I can notice that in ArgsParser.java, we will check the validlity of the sincedate and untildate using some functions provided by TestUtils.java. In particular, TimeUtil.verifySinceDateIsValid(sinceDate); and TimeUtil.verifyDatesRangeIsCorrect(sinceDate, untilDate);.

1. My current plan: Based on the name of the method, I am planning to extend the method TimeUtil.verifyDatesRangeIsCorrect(sinceDate, untilDate); and limit the possible date ranges of both sinceDate and untilDate to be between 1970-01-01T00:00:00UTC and 2099-12-31T23:59:59UTC.

2. Can I kindly check the expected behaviour if such invalid dates are found? Should we reset the dates automatically or throws a ParseException?

Thanks!

[dcshzj]

@litone01 Your implementation plan sounds correct. For now, let's reset the dates but send a warning message to the log to let the user know that we are resetting the dates.

[bingsen0806]

Hi, may I know if anyone is currently working for this. I am a new contributor and would like to work on this

[litone01]

Hi, may I know if anyone is currently working for this. I am a new contributor and would like to work on this

Hi so sorry for holding off this issue. I am not working on it currently. Please check with the maintainers and if they are ok with it, please feel free to proceed. Thanks.