Bug: CaseContact form date input

[thejonroberts]

What github issue is this PR for, if any?

Addresses #5860

What changed, and why?

Javascript is running (on any page load app wide) that manipulated #case_contact_occurred_at field value if it was present. This was probably to ensure it matched previous date picker library format, but app uses browser date pickers now. The manipulation may have been the cause of bug - we have not been able to reproduce the issue. Even if not, this brings date selection in line with standard validation.

• Remove offending javascript
• Swap date range picker component (partial) that worked with it, in favor of standard rails form.date_field , plus proper attributes for browser validation, using iso8601 date format standard for browsers
• Change occurred_at 'not in future' validation from custom method to comparison (as we validate minimum date)
• Use MINIMUM_DATE model class constant to ensure form and model use same date.
• Remove the components/dead javascript that aren't used after the change

How is this tested? (please write tests!) 💖💪

Unsure how to test as not able to reproduce/browser specific. I think existing system new/edit specs do a lot of date inputting, so I think that's sufficient, but open to suggestions.

Feelings gif (optional)

[thejonroberts]

Could drop these min/max attributes to handle with model validations only (allow submit & show validation errors). This will prevent selecting bad dates via UI, but user can still type them in, afaik.

[elasticspoon]

I good with this as if, thanks. Love removing unnecessary dependencies.

There is existing issue where the current inputs don't take into account the timezone of the user is not getting used. So if I enter 8/10/2024 that is saved at 8/10/24 UTC and if I later convert that to EST it becomes 8/9/24 EST.

It would be cool if that could be covered in this PR but I'm totally fine with that being a different PR as well. (Also I'm not 100% if we use the occurred_at with a timezone)

[thejonroberts]

I good with this as if, thanks. Love removing unnecessary dependencies.

There is existing issue where the current inputs don't take into account the timezone of the user is not getting used. So if I enter 8/10/2024 that is saved at 8/10/24 UTC and if I later convert that to EST it becomes 8/9/24 EST.

It would be cool if that could be covered in this PR but I'm totally fine with that being a different PR as well. (Also I'm not 100% if we use the occurred_at with a timezone)

Yes, feels great when a PR is more red than green!

There is some code that grabs time zone from a browser cookie (browser_time_zone from Users::TimeZone concern), but I don't think it's being used here (or CaseContact show). It's set by app/javascript/src/time_zone.js.
Definitely worth thinking about and testing a little better, but I think it would take some time to dig around and be really consistent.

Time is always tricky, I like to refer to this thoughtbot article a lot... Might be worth adding a user timezone column for the user to be able to choose? Or having a good fallback.

[elasticspoon]

I think this PR is kind of the idea of how we would do it in this code base but I guesstimate there are more places incorrectly using timezones than correctly at the moment.

[thejonroberts]

The occurred_at param is a plain date, sent without any tz info, so saving to UTC, which is good. Potential issues if user is on the 'other side' of the date line from UTC.

• User Behind => form prefilled date is a day later than expected (tomorrow from user perspective).
• User Ahead => validation fails because they are 'in the future' (tomorrow from server perspective).

America/New York is 4 hours behind UTC, so the first scenario could be happening after 8pm Eastern for users. It may be annoying but not blocking creation, and doesn't sound like this bug as reported.

I think incorporating browser_time_zone would be beneficial, but perhaps separate from this work?

[elasticspoon]

The occurred_at param is a plain date, sent without any tz info, so saving to UTC, which is good. Potential issues if user is on the 'other side' of the date line from UTC.

* User Behind => form prefilled date is a day later than expected (tomorrow from user perspective).

* User Ahead => validation fails because they are 'in the future' (tomorrow from server perspective).

America/New York is 4 hours behind UTC, so the first scenario could be happening after 8pm Eastern for users. It may be annoying but not blocking creation, and doesn't sound like this bug as reported.

I think incorporating browser_time_zone would be beneficial, but perhaps separate from this work?

Yea for sure not part of this. I was just mentioning it in general. And I has been reported with regards to some notification and email tables in the past.