DARIAEngineering/dcaf_case_management

Accommodate funds/users in different time zones than eastern time

Closed this issue · 7 comments

colinxfleming commented

Thanks for creating an issue! Please fill out this form so we can be sure to have all the information we need, and to minimize back and forth.

  • What are we trying to do?

I believe DARIA saves data in ET but some funds are very much not in ET, so we should accommodate that case based on organization (or local user/client).

  • What feature or behavior is this required for?
    dates and times that make sense

  • How could we solve this issue? (Not knowing is okay!)
    no idea, but time to go fishing.

  • Anything else?

colinxfleming commented

One significant (annoying) way this plays out is that Sunday night work in mountain time orgs shows up as Monday morning work because of the app being set to eastern time. Although eastern time is known to be the best time zone this is less helpful.

  • 😄1
mercedesb commented

I'd be down to take this on if it fits within current priorities.

colinxfleming commented

@mercedesb yeah for sure! I'll write up a little more context on this tonight or tomorrow and send you off to the races

mercedesb commented

Awesome! In case it's helpful and saves you any time, this is what I was thinking initially after poking around the code a bit.

  • add timezone as a valid config_key to the Config model
  • update views/controller to allow funds to set their timezone (default to ET)
  • update all dates to display with the config timezone
    • helper already exists for Date and Time to display_date. we can check for ActsAsTenant.current_tenant and if it exists, display the date/time in the fund's timezone
  • don't touch the dates in the db, they can keep saving the way they currently are

There are probably other dates/times that this initial pass doesn't account for but hopefully reacting to an idea is quicker than writing up all the context :)

colinxfleming commented

honestly I think that handles probably 90% of it, and if you want to get rolling on that it would be amazzzzzinggggg. @elimbaum has written a lot of our Config code, so you can take a gander at his recent PRs for some stuff on how to add new configs.

The one other thing that I know will definitely need some attention (and to be clear, this can be done separately, it's a tougher nut to crack) is Patient.pledged_status_summary. What this does is generates the data that populates the budget bar at the top of the call list dashboard; that's also time/day sensitive and will require some offsetting.

But the config stuff is a prereq either way, so I'd say take a run at the Config + display date stuff as you lay it out here! And we'll get that in for a major quality of life improvement to start, and run with it further.

A truly stupid side note, I think I miiiight have system time of this rails app set to eastern (an artifact from when we were dcaf exclusive). I'll check on past me's bad choices this week as well.

thank you @mercedesb !

  • 🚀1
mercedesb commented

A truly stupid side note, I think I miiiight have system time of this rails app set to eastern

:) Yes, the system time is Eastern but I don't think it's that stupid. It made sense at the time. And it doesn't make converting between the timezones any harder than from UTC. So I don't think it's a thing we really need to worry about at the moment.

I'm about to push up a PR for the first part of this (Config + displays). I'm currently working on the Patient.pledged_status_summary. It's pretty straightforward but I'd like to flesh out the test cases so I can make sure I'm not introducing any regressions. I should have that done within a few days and I'll open a 2nd PR for that.

mercedesb commented

Patient.pledged_status_summary took less time than I expected so I included it in #2838 rather than opening a separate PR. Happy Friday!