4 ms·

I'm building a fairly large SaaS product that will have global users and show financial reporting across different regions. Nothing gives me more anxiety as a r

I'm building a fairly large SaaS product that will have global users and show financial reporting across different regions. Nothing gives me more anxiety as a relatively new developer than storing and recalling date/time values from my Postgres database, being converted to/from/being displayed in my app. I have all records stored in timestampz(3), but I have no idea if what I'm doing is best practice or how to audit said functions. Using luxon at the moment, but a guide or blog post for best practices would help put my mind at ease if anyone has one. I know dates as a library are complex, but the UX managing them isn't much better.

jpalawaga 1y ago
in general, backend life becomes way, way easier if you just store everything in zulu time, transmit in zulu, and localize it on the frontend (which is what javascript does by default anyhow, iirc). maybe there are some cases where you want to store the timezone (e.g. you've displayed a datepicker and the user has expressly entered a timezone)--but normally you'll save headache by storing everything in zulu time. if storing the timezone is important for those transactions, then I could potentially see that as warranting storage with a timezone as well. basically, ask 'if the timezone matters' with respect to the information being encoded. if it's just for display purposes and can be ignored, then KISS.
petersellers 1y ago
When dealing with timestamps, it's easiest to store and process them in UTC for as much of your code as possible. This means pretty much all of your backend and database code. Only convert these values from UTC to other timezones when presenting this data to the user (at that point, you'd need to take the user's timezone(s) into account).