9 ms·

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.cre

by 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.
feld 11y ago
I disagree. Storing as UTC is the only sane way. It will never get corrupted. Calculating the timezone difference for the user is not that hard and won't result in a database full of mistakes you have to scramble to fix.
- Avernar 11y ago
  Not for events like shows, movies, work hours, etc. An event starts and stops at a specific local time. If the DST rules change then the UTC version will be wrong but the one stored in local time + TZ will be correct. Intervals should be stored in UTC. If you're supposed to drop the control rods in a reactor in 24 hours you store the time it's supposed to happen in UTC. DST transitions and rule changes would mess this up if stored in local time. Timestamps for logs and files should also always be UTC.
  - feld 11y ago
    UTC is an anchor. It does not change, it is never wrong. Your application or environment may live under different rules because of location but that problem can be solved by the timezone-aware application. If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00 UTC. If my timezone changes due to a new law UTC is not wrong; the event is still going to happen at 13:00 UTC! If the event was previously stored as a local time and not UTC the EVENT is wrong! You solve this by handling the TZ conversion elsewhere and making sure it always has the latest rules. Always store in UTC. Your argument makes no sense.
    - laut 11y ago
      If the user expects 8:00 local time then it should stay 8:00 local time. That is at least how people would want their applications to work 99% of the time. If someone enters 8:00 and then the software suddenly changes it to something else, that is confusing. If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
      - 11y ago

by laut 11y ago

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.

feld 11y ago

I disagree. Storing as UTC is the only sane way. It will never get corrupted. Calculating the timezone difference for the user is not that hard and won't result in a database full of mistakes you have to scramble to fix.

Avernar 11y ago
Not for events like shows, movies, work hours, etc. An event starts and stops at a specific local time. If the DST rules change then the UTC version will be wrong but the one stored in local time + TZ will be correct. Intervals should be stored in UTC. If you're supposed to drop the control rods in a reactor in 24 hours you store the time it's supposed to happen in UTC. DST transitions and rule changes would mess this up if stored in local time. Timestamps for logs and files should also always be UTC.
- feld 11y ago
  UTC is an anchor. It does not change, it is never wrong. Your application or environment may live under different rules because of location but that problem can be solved by the timezone-aware application. If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00 UTC. If my timezone changes due to a new law UTC is not wrong; the event is still going to happen at 13:00 UTC! If the event was previously stored as a local time and not UTC the EVENT is wrong! You solve this by handling the TZ conversion elsewhere and making sure it always has the latest rules. Always store in UTC. Your argument makes no sense.
  - laut 11y ago
    If the user expects 8:00 local time then it should stay 8:00 local time. That is at least how people would want their applications to work 99% of the time. If someone enters 8:00 and then the software suddenly changes it to something else, that is confusing. If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
    - 11y ago