4 ms·
In our case, the admins who create/manage those events have to specify the event location, so we fetch the timezone for that location and if there's any mismatc
by Khao 11y ago
In our case, the admins who create/manage those events have to specify the event location, so we fetch the timezone for that location and if there's any mismatch, they can change the timezone manually. Since we migrated all the data, we have not received a single bug report for an issue that was caused by DST or from converting UTC times to local timezones.
- vemv 11y agoI retract my opinion - the approach is clearly correct for that business domain. The key difference is here: > The thinking is that if a client is shopping for a class in a different timezone, why would we convert the class's time to the client's timezone? It makes no sense. Roughly speaking, basically there are two kind of apps: - apps where datetime values need to be localized ("this message was sent at 18:00") - apps where datetime values need to reflect a fixed timezone ("we will meet in Madrid, at 18:00 local time")
- Khao 11y agoIn our app, everything that's a timestamp (invoices, payments, registering to an event, sending messages, create/update timestamps, etc..) is stored in UTC. Having both depending on the use case is really the best for us.