Spike: review TIME for scheduled_for and determine how to improve it

[cris-oddball]

User Story - Business Goal

The v2 and v3 notification routes have a scheduled_for property (a permission that must be added to any service that wishes to use it) that can be sent in the POST payload. Testing has revealed that the routes do send scheduled emails and sms however there is a time factor that must be addressed.

Note that v3 implementation is partial and is also different than the v2 implementation. Review both to determine what changes need to be made to each and create appropriate tickets.

• [ ] Ticket is understood, and QA has been contacted (if the ticket has a QA label).

User Story(ies)

As a VANotify I want to spruce up the notifications scheduled_for feature So that I can provide that functionality to clients

Additional Info and Resources

• Read the investigation and testing document created by QA
• The earliest a notification can be sent is 7 hours from present (at least when testing in MDT, which is UTC-6); this will of course vary by what time zone you are in. For the east coast, the earliest a notification could be sent is 5 hours from the present.
• The property expects a value in this format: "2023-09-06 17:00" or %Y-%m-%d %H:%M, based on the code.
• This time must be in UTC. If you try to any US time zone's time, you will get an error stating that scheduled_for cannot be in the past (because our offset is behind UTC, maybe this feature works as expected in Ukraine).
• You can't pass along your TZ with that format.
• Once created, the scheduled_for value in the GET response is not the value you sent, but 8 hours in the future.
• Based on the scheduled_for value in the GET response, the notification is actually received 4 hours earlier than that (but 4 hours later than what the scheduled_for value was in the POST request. See Testing Doc
• The application appears to use "America/New York" as its timezone while the DB uses UTC., which may be a factor here.

Acceptance Criteria & Checklist

• [ ] Technical Documentation has been created and linked in the glossary
• [ ] Learnings have been shared with the team, and decisions have been documented
• [ ] Tickets for next steps have been identified and created

Completed research addresses the problems and/or answers the questions below:

1. We understand how Scheduled feature works and how to improve it for our clients.
2. Determine if it is valuable for the client to be able to send along a TZ in the timestamp. The code appears to do a conversion, so the value might be sent in this format:%Y-%m-%dT%H:%M:%S.%fZ
3. If that is not valuable for the client and we inform the clients that the TZ they send must be in UTC, then the insertion into the DB must be the value that was sent, not a value that adds any amount of time to it.
4. Determine if it makes more sense for the app and the DB to be in the same timezone (and what impact, if any, the current state has on billing data)

[kbelikova-oddball]

Hey team! Please add your planning poker estimate with Zenhub @k-macmillan @kalbfled @MackHalliday @mchlwellman @EvanParish @cris-oddball @coreycarvalho

[mjones-oddball]

@cris-oddball can you migrate a PDF copy of your testing document to the team repo (or make into an MD file) and update the links in the ticket when you get a chance?

[cris-oddball]

@mjones-oddball will do, on my todo list!

[cris-oddball]

Testing doc added to team repo and linked in description.

[npmartin-oddball]

Still broken/still needed.