darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2026-02-04 02:11:11 -05:00
Code Issues Packages Projects Releases Wiki Activity

update 0002 for et instead of utc

Browse Source
This commit is contained in:
Steven Reilly
2023-11-02 16:01:15 -04:00
committed by GitHub
parent c653b63067
commit 2883b93ba2
1 changed files with 9 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/adrs/0002-how-to-handle-timezones.md
View File

@@ -1,9 +1,9 @@
# TITLE: Determine How to Handle Timezones in US Notify
| CREATED DATE | LAST UPDATED | STATUS | AUTHOR | STAKEHOLDERS |
| CREATED DATE | LAST UPDATED | STATUS | AUTHOR |
| :---: | :---: | :---: | :---: | :---: |
| 06/06/2023 | 06/15/2023 | Accepted | @terrazoon, @ccostino | @GSA/notify-contributors |
| 06/06/2023 | 11/02/2023 | Accepted | @terrazoon, @ccostino |
## CONTEXT AND PROBLEM STATEMENT
@@ -106,15 +106,11 @@ Cons of converting parts of the frontend now:
customization, if any.
## CHOSEN OPTION: Backend UTC, frontend UTC
## CHOSEN OPTION: Backend UTC, frontend explicitly ET
After talking through each of these options together as a team, we have decided
to move forward with converting the backend to UTC fully and pairing that work
with displaying UTC in the frontend where need be.
@terrazoon had an [open PR](https://github.com/GSA/notifications-api/pull/272)
with most of the work already accounted for, and explained the rationale for
making the change based on previous work and project experience.
with displaying ET in the frontend where need be.
Multiple team members also spoke about the benefits of storing, processing, and
managaging timezones as only UTC in the backend of the system and that it's
@@ -122,25 +118,11 @@ worth the additional work to implement. The challenges inherent in trying to
manage timezones directly are too many and greatly increase the risk of new bugs
and undesired behavior and side-effects being introduced into the system.
### Consequences
- Positive
- Work was already partially complete for the backend adjustment.
- Consistent handling of timezones with just UTC across the system in the
backend.
- Provides support to adjust the frontend and other clients as desired going
forward.
- Negative
- The additional work includes updating tests to make sure they all continue
to work properly.
- User testing will also have to be conducted to account for both the app
still functioning properly and noting where in the UI/frontend things will
need to change.
Previously, using UTC in the UI as well proved that UTC is unclear to nearly all
users. ET is a more understandable and expected default.
## VALIDATION AND NEXT STEPS
## NEXT STEPS
With the decision to move the backend to UTC, the following actions need to be
taken:
@@ -157,9 +139,8 @@ taken:
We also need to update the frontend to account for these changes. This will be
done in two parts:
1. We'll update the UI to make sure everything reflects UTC where necessary for
any timzone displays. This work will be tracked in this issue:
https://github.com/GSA/notifications-admin/issues/525
1. We'll update the UI to make sure everything reflects ET where necessary for
any timzone displays.
1. We need to create an ADR for future frontend work for how we'd like to handle
timezones in the UI going forward. This is currently noted in this issue: