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 things handled in that timezone. The wheels fall off the wagon if we try and combine data from multiple locations into a single database; 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 determine an actual point in time that something happened at. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
