Yeah, another way to think about it is whether you're: * Storing info about an instant in time when something happened (or is going to happen), which would be

Yeah, another way to think about it is whether you're: * Storing info about an instant in time when something happened (or is going to happen), which would be the same across the entire universe (relativity notwithstanding) * You're storing info about when something should happen (or something happen) in the context of a specific location Typically, if you're recording things that happened (think logging an event), then you want to store the instant that they happened. This means storing them in UTC and translating to the user's time zone on display. If you're storing info about when something should happen (think of an appointment or meeting) then you want to store it in the context of a single, specific location, and translate to other user's time zones on demand. Scheduling for future events should always be in the context of a specific time zone or location. If someone from another time zone needs to see the translation into their time then you apply the what the differential will be between the two time zones at the time the event is supposed to occur in the source time zone (so if the destination time zone will be +6 at the date/time of the event in the source tz then you add 6 hours to the source date/time). It's complicated doing it like that but it's the only way to account for all the various ways TZs can change that you hadn't accounted for. The key is understanding what you're measuring date/time relative to.