Make Default Date in Case Contact Form The Current Date Regardless of Time of Day

[CovenantHuman]

Impacted User Types

• volunteers
• supervisors
• admins

Environment

Production

Current Behavior

The default date for a case contact should be the current date but it is showing up as one day in the future. Note in this screen shot at the bottom right my computer has the date as 9/6/2021, where as in the center of the CASA page under Occurred At the date is shown as 2021/09/07, the next day. This is likely a matter of using UTC rather than the current time zone.

Expected Behavior

The default date for a case contact should be the current date in the time zone of the person using the site.

How to Replicate

1. • Wait until after the date has changed UTC but before it has changed in your local time zone, or change your computers local time accordingly.
2. • Log into qa as [email protected], password: 12345678
3. • Scroll down to Occured At, and note the date as compared to the date where you are.

[acrosman]

I mentioned this issue in Slack, and having gotten a positive response am summarizing my thoughts here.

The proposed solution on this issue is unlikely to be correct in most use cases. The application's time zone should match the program office, and the added complexity of an override from the user's location adds complexity to the tool without additional value to the user.

Because Casa programs are inherently local, the application time should default to the timezone of the program's main office. UTC is only correct for programs in Europe and Africa (and I'm not aware of any). In the rare cases where the volunteer is in a different time zone from the the staff, it is likely to be off by no more than an hour and the chances of data entry near midnight is small. But if the person doing data entry is in a different time zone from the program's office, and it matters, the most likely cause is travel by a volunteer for non-Casa reasons (like business trips that happen just after a visit, or a call taken while traveling). In those cases either the date is likely to be hand set anyway, or the program date is the more correct one since that is more likely to be the child's. After that we get into really complex edge cases that probably aren't worth trying to predict.

If the application doesn't allow for easy time zone setting that might be needed (in truth I haven't looked at that detail of the setup).

[librod89]

This issue is related to https://github.com/rubyforgood/casa/issues/2370

[acrosman]

To me this still feels like the application itself is operating in the wrong timezone not that it should be dynamically adapting the user's browser. An instance-wide setting should be easier to maintain than a user-by-user behavior. Is the intended design that all instances of Casa run in UTC and so a setting needs to be added to adjust to the local timezone of the program? Or is this instance configured to use UTC instead of the program's local (Eastern Time most likely)?

[compwron]

All dates stored in a database should always be in UTC We should probably start capturing casa org timezone and using it

[mgrigoriev8109]

@CovenantHuman / @compwron (wasn't too sure who to ping), I can work on this.

I plan to implement this by first heading to /casa/spec/views/case_contacts/new.html.erb_spec.rb and making the first test it { is_expected.to have_field("c. Occurred On", with: current_time) } fail by adjusting the case_contacts factory over in /casa/spec/factories/case_contacts.rb from occurred_at { Time.zone.now } over to Time.now.utc.

This factory is also used over in /home/mgrigo/casa/spec/views/case_contacts/edit.html.erb_spec.rb, where I can make that test fail by adjusting line 37 expect(rendered).to include(case_contact.occurred_at.strftime("%Y-%m-%d")) over to expect(rendered).to include(current_time) and adding let(:current_time) { Time.zone.now.strftime("%Y-%m-%d") } over to the top of the test.

Now both tests should fail when the current time zone is a day ahead of UTC, I can adjust both tests' current_time to be Time.now.utc so that they pass, and making a similar change over to app/views/case_contacts/_form.html.erb on line 69 from <% occurred_at = @case_contact.occurred_at || Time.zone.now %> over to || Time.now.utc

I do however have two questions that should probably be addressed in separate PR's:

1. The app displays Occurred At over in the reimbursementsview, andOccurred Onin the views I discussed above. The variable, however, is alwaysoccured_at. Should I make a PR to have some consistency - having the views and variable be identical? So everything is either Occurred AtorOccured On?
2. Time.zone.now is used in 19 total places throughout the codebase. Do we want to default to using Time.now.utc in all those occurrences and have that be the standard - so that times don't mismatch?

[compwron]

sounds good!

1. yes consistency please, separate PR good

2. correct, .utc. thanks!

[mgrigoriev8109]

@compwron so digging into time zones a bit more https://thoughtbot.com/blog/a-case-study-in-multiple-time-zones https://thoughtbot.com/blog/its-about-time-zones

I understand the conversation between you and acrosman a bit more, , and also also see that my proposed solution is silly - both Time.zone.now and Time.now.utc currently yield UTC, since UTC is the default time Rails time zone.

So my proposed changes wouldn't actually change anything in terms of functionality, and unless I'm wrong this issue in particular can be closed since the codebase does currently use the desired timezone (UTC).

However should there be two new issues opened?

We should probably start capturing casa org timezone and using it

yes consistency please, separate PR good

So

1. An issue for capturing the casa org timezone and using it (no clue how I would do this, lol)
2. An issue for changing all Occurred On and occurred_on into Occurred At and occurred_ats.

[github-actions[bot]]

This issue has been inactive for 250 hours (10.42 days) and will be unassigned after 110 more hours (4.58 days). If you have questions, please

If you are still working on this, comment here to tell the bot to give you more time

[github-actions[bot]]

This issue has been inactive for 370 hours (15.42 days) and is past the limit of 360 hours (15.00 days) so is being unassigned.You’ve just been unassigned from this ticket due to inactivity – but feel free to pick it back up (or a new one!) in the future! Thank you again for your contribution to this project.

[bcastillo32]

@mgrigoriev8109 are you still working on this? :)

[jsobralgitpush]

Hello, everyone!

Can i work on this one? :)

[compwron]

I am closing this as old. We may rediscover and reopen it.