5 ms·
Time stamp + TZ is a useful feature if you want to store TZ along with the time stamp. But I think that’s nearly always a bad approach. The only part of your sy
by AmericanChopper 6y ago
Time stamp + TZ is a useful feature if you want to store TZ along with the time stamp. But I think that’s nearly always a bad approach. The only part of your system that needs the time stamp converted into a TZ is your human user. Performing that conversion on the presentation layer will almost always lead to less complexity.
- unilynx 6y agoThe most common situation I know of where you store the time with its original TZ is when dealing with recurring times (opening/closing items, appointments), as you need to follow the original DST/summertime the user was in. Which also requires you to store the TZ location (ie city) and not just the name or offset of the timezone itself.
- AmericanChopper 6y agoYeah, I meant to put a “usually” qualifier in that previous comment. Rostering has the same problem. Event scheduling can also run into similar problems. The best solution really depends on a lot of context specific details, but most of the better solutions I’ve personally seen have put TZ in a seperate field, rather than using TZ-typed timestamps, and then use the TZ when required instead of as the default storage format.
- rocqua 6y agoFor recording when something happend, that makes some sense. Though if you want to report the day of an event, it is still neccesary to include a timezone. For planned events, it becomes really hard to determine what to do when changing locale.