Josh, On 8/27/08, Josh Berkus <[EMAIL PROTECTED]> wrote:
> The use cases I have encountered, many times, are: > > (1) Single-time-zone micro-applications: when the user doesn't want to be > bothered with time zones because they're 100% in a single time zone. These > users want "Timestamp Ignoring Time Zone" where timestamps are treated like > they are always in UTC. > > (2) Multiple-time-zone applications, where each user wants to see the data > in their *own* time zone. In this case, the *client protocol or driver* > should accept timestamps with time zones, convert them to UTC, and store > them. On retrieval, the timestamps should again be converted by the > client/driver into the local time zone of the user, unless the user asks for > the timestamp in some other time zone. > > In neither case does it make any sense to store the "recorded" time zone in > the database. > > Some of you will find the above timestamp logic quite familiar from another > database product. I am biased towards that implementation because I helped > develop it, based directly on my development of 3 different calendaring > applications. What are the ramifications of this with regards to internal timestamp functions? Is CURRENT_TIMESTAMP() converted to UTC even if the server is not in UTC? That's my main concern; right now MySQL just stores what you give it, no conversions, no work for MySQL. If the server is not in UTC and Drizzle has to convert it, that's adding a (potentially hairy) feature. But...I defer to actual experience coding and using, not just my experience using. -Sheeri
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
