darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2026-02-05 02:41:14 -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 # 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 ## CONTEXT AND PROBLEM STATEMENT
@@ -106,15 +106,11 @@ Cons of converting parts of the frontend now:
customization, if any. 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 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 to move forward with converting the backend to UTC fully and pairing that work
with displaying UTC in the frontend where need be. with displaying ET 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.
Multiple team members also spoke about the benefits of storing, processing, and 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 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 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. and undesired behavior and side-effects being introduced into the system.
Previously, using UTC in the UI as well proved that UTC is unclear to nearly all
### Consequences users. ET is a more understandable and expected default.
- 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.
## VALIDATION AND NEXT STEPS ## NEXT STEPS
With the decision to move the backend to UTC, the following actions need to be With the decision to move the backend to UTC, the following actions need to be
taken: taken:
@@ -157,9 +139,8 @@ taken:
We also need to update the frontend to account for these changes. This will be We also need to update the frontend to account for these changes. This will be
done in two parts: done in two parts:
1. We'll update the UI to make sure everything reflects UTC where necessary for 1. We'll update the UI to make sure everything reflects ET where necessary for
any timzone displays. This work will be tracked in this issue: any timzone displays.
https://github.com/GSA/notifications-admin/issues/525
1. We need to create an ADR for future frontend work for how we'd like to handle 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: timezones in the UI going forward. This is currently noted in this issue: