On May 27, 2011, at 6:29 PM, Greg Stark wrote:
> Both of these two cases can be handled differently. The former by
> storing the raw text inputs and then storing the interpreted value as
> a derived column separetly, and the latter by storing the local time
> zone to use for display as an additional attribute along with the
> local address and other attributes of the calendar event.
Which means you're back to a very cumbersome method that involves another field. That's a tremendous amount of extra
code.
We run multiple businesses around the globe. Each business operates in it's own timezone, and 90% of the time we want
thingshandled in that timezone. The wheels fall off the wagon if we try and combine data from multiple locations into a
singledatabase; there's no reasonable way to say: give me the data in this field *at the timezone that was originally
entered*,except for not storing timezone data at all. If we don't store timezone data at all, then it's impossible to
determinean actual point in time that something happened at.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
