remove timezone offsetting from date range methods

[shubham1g5]

Summary

This is to fix DateRangeUtilsTest which fails in certain timezones.

The date range method parseHumanReadableDate is used in case search date range widget to convert a text date range like 12-07-2023 to 14-07-2023 to time in milliseconds to set the range to the date widget. This method currently offsets the time in milliseconds for the current timezone. That doesn't seem correct to me as that can lead to dates being different on date widget in comparison to what is provided in the String. Instead we should just be returning the dates in current time zone so that they are consistent between their string manipulation and date widget.

This method itself was added in this PR for context and I can't seem to remember why I decided to offset the timezone earlier.

Feature Flag

CASE_SEARCH

Safety Assurance

• If the PR is high risk, "High Risk" label is set
• I have confidence that this PR will not introduce a regression for the reasons below
• Do we need to enhance manual QA test coverage ? If yes, "QA Note" label is set correctly

Automated test coverage

Change itself is to fix a test

Safety story

Change is Limited to date range widget used in case search

QA note: Check for date range widget in case search working correctly across a few different timezones.

[avazirna]

@shubham1g5 I might not have full context here, but I think this was done because we store dates in UTC in HQ, so the offsetting is to match the format in which the date is stored perhaps. But I agree that we probably don't need this as it's a date based search, so we don't care much about the timestamp, but we might want to check if the way we are querying is inclusive regarding the end date, i.e. we could be leaving cases out if in the comparison the end date is set as 12-07-2023 00:00:00 and not 12-07-2023 23:59:59 (or completely ignoring the timestamp).

[shubham1g5]

@avazirna I don't think that's the reasoning there. We are passing these dates to the case search API as an inclusive range 15-03-2023_to_17_03_2023. Today this sometimes gets changed to +- 1 day such as 14-03-2023_to_16_03_2023 depending on the timezone which will remove some required results and add other unrequired results to the search results. So I don't think we want to do that kind of manipulation on results. The bigger issue here is it's not consistent with what user sees on the case search input (use sees a date like 15-03in the text field marked as 14/03 on the date widget)

@damagatchi retest this please