search

bcgov / zeva

Zero Emission Vehicles Act
Apache License 2.0
5 stars 13 forks source link

ZEVA - Update Date/Time Storage #2098

Closed shayjeff closed 8 months ago

shayjeff commented 9 months ago

Describe the Bug Some credit application timestamps are displaying with tomorrow's date due to storing dates in UTC+00 (GMT) in the database; dates should be displayed in PST.

Expected Behaviour Timestamps should reflect the local time of PST instead of UTC, ensuring accurate date representation.

Actual Behaviour Timestamps in the credit application display tomorrow's date because of the UTC+00 (GMT) storage in the database, leading to, in some cases, a date and time discrepancy.

Implications Inconsistency in date representation in the application.

Steps To Reproduce Steps to reproduce the behaviour: User/Role: Analyst, in production, at time of this writing:

  1. Go to the credit applications list page
  2. See date for application 525

Additional information See Django's documention on timezone support: https://docs.djangoproject.com/en/5.0/topics/i18n/timezones/#overview

image
kcabhar commented 9 months ago

Hey team! Please add your planning poker estimate with Zenhub @JulianForeman @tim738745

emi-hi commented 8 months ago

from the django documentation:

Even if your website is available in only one time zone, it’s still good practice to store data in UTC in your database. The main reason is daylight saving time (DST). Many countries have a system of DST, where clocks are moved forward in spring and backward in autumn. If you’re working in local time, you’re likely to encounter errors twice a year, when the transitions happen. This probably doesn’t matter for your blog, but it’s a problem if you over bill or under bill your customers by one hour, twice a year, every year. The solution to this problem is to use UTC in the code and use local time only when interacting with end users.