5 ms·

Seems a misguided practice to me. * Store datetime values in UTC. Else you get inconsistent values, which has unpredictable consequences. * Detect user's expe

by vemv 11y ago

Seems a misguided practice to me. * Store datetime values in UTC. Else you get inconsistent values, which has unpredictable consequences. * Detect user's expected timezone using one of : a) user preference setting, b) the region the app is supposed to be running for, c) IP geolocation. Choice depends on the app requirements. Don't default to any timezone unless considered 100% safe. * Present DB values in the UI using said detected timezone. * UI-wise, slways display timezone information for datetime values. At the very least in a tooltip.

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 ago
  I 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 ago
    In 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.
laut 11y ago
It is not misguided, it is a good practice. Read more about why here: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...
- Someone1234 11y ago
  One edge case doesn't disprove a rule, and timezone/DST rules changing is definitely an edge case. For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones. Storing in local and then converting from one timezone to another timezone on demand has far more edge cases and gotchas. Plus it too isn't immune from rule changes, if you store in local time (e.g. 10 am) but DST rules changes, from an outside observer's perspective (someone in any other timezone) the meeting's time has now changed. So even just using that edge case you're talking about exchange one downside (local time changes) to another downside (remote time changes).
  - jasode 11y ago
    >For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones. Saving as UTC doesn't really solve the issue (although it seems like it does). The issue that the previous posters (Khao, laut) didn't make explicit is that we have 2 concepts of datetimes: 1) scientific datetime (which UTC is unambiguous, except for obscure things such as leap seconds) 2) socially-constructed datetime (which "local" time + TZ resolves most (but not all) of the ambiguities) Scientific(UTC) datetime works great for past events like server logs, and some types of future events such as celestial events. For example, the upcoming solar eclipse in August 21 2017. Regardless of what future DST rules are decreed by the government, the moon is going to move in front of the sun at a 16:48:33 UTC time. Socially-constructed future datetime such as appointments don't work the same way. For example, we presume that a Super Bowl on the east coast in the year 2025 will have a kick off of 6:30pm but we can't encode that as UTC unambigously because we don't know today what DST rules will be in effect 10 years from now. In 2016, we don't know whether to encode it as 22:30UTC or 23:30UTC. That said, if the planning horizon is short (such as sending out alerts for an upcoming conference call to participants spanning timezones), one can encode it as UTC internally and then decode it to local wall-clock time. It may be simpler that way with less bugs.

by vemv 11y ago

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 ago
I 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 ago
  In 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.

laut 11y ago

It is not misguided, it is a good practice. Read more about why here: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...

Someone1234 11y ago
One edge case doesn't disprove a rule, and timezone/DST rules changing is definitely an edge case. For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones. Storing in local and then converting from one timezone to another timezone on demand has far more edge cases and gotchas. Plus it too isn't immune from rule changes, if you store in local time (e.g. 10 am) but DST rules changes, from an outside observer's perspective (someone in any other timezone) the meeting's time has now changed. So even just using that edge case you're talking about exchange one downside (local time changes) to another downside (remote time changes).
- jasode 11y ago
  >For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones. Saving as UTC doesn't really solve the issue (although it seems like it does). The issue that the previous posters (Khao, laut) didn't make explicit is that we have 2 concepts of datetimes: 1) scientific datetime (which UTC is unambiguous, except for obscure things such as leap seconds) 2) socially-constructed datetime (which "local" time + TZ resolves most (but not all) of the ambiguities) Scientific(UTC) datetime works great for past events like server logs, and some types of future events such as celestial events. For example, the upcoming solar eclipse in August 21 2017. Regardless of what future DST rules are decreed by the government, the moon is going to move in front of the sun at a 16:48:33 UTC time. Socially-constructed future datetime such as appointments don't work the same way. For example, we presume that a Super Bowl on the east coast in the year 2025 will have a kick off of 6:30pm but we can't encode that as UTC unambigously because we don't know today what DST rules will be in effect 10 years from now. In 2016, we don't know whether to encode it as 22:30UTC or 23:30UTC. That said, if the planning horizon is short (such as sending out alerts for an upcoming conference call to participants spanning timezones), one can encode it as UTC internally and then decode it to local wall-clock time. It may be simpler that way with less bugs.