Giuseppe Maxia wrote: > On Wed, Aug 27, 2008 at 6:50 PM, Sheeri K. Cabral <[EMAIL PROTECTED]> wrote: >> On 8/27/08, Jay Pipes <[EMAIL PROTECTED]> wrote: >>> Couldn't agree more. TZ belongs in the application layer, which knows >>> best about conversions and locales. UTC in the DB is the way to go IMHO. >> OK, only one thing -- it's not that UTC is stored in the db, it's that there >> is no timezone information stored along with the datetime in the db, and the >> *assumed* timezone is UTC. >> >> I bring this nitpicky point up because it's all relevent to how NOW() and >> SYSDATE() and CURRENT_DATE() and CURRENT_TIME() and other date/timestamp >> stuff works. >> >> Do we trust 100% that the user/application will do the right thing? Or do >> we accept timezones and issue an error if the timezone isn't UTC? Or a >> warning, that we're doing an implicit conversion (usually bad to do this >> type of thing)? >> >> If we say "no timezones no how no way no chance" then we trust 100% that the >> user/application does the right thing, and if they just hardcode what the >> app code says is "now" into a query, then you still have the problem that >> people are *storing* in their timezone, complete with daylight savings time, >> etc. >> >> -Sheeri >> > > One of the reason for complaining against MySQL shortcomings was that > the implementation of many features did not take user needs into > account. > The implementation makes perfect sense to the developers, but the > users are not considered at all. > Let's not repeat the same mistakes with Drizzle! > > Timestamps with time zone information are quite common (blog XML > feeds, web server logs), and the user must have a way of inserting > that information without need to write an application.
The "user" of the database is the developer. > Think about this: I have some data to insert, and an application that > does not know about TZ. If the database recognizes TZ extensions, I > just feed the data in. If it doesn't I need to code (or pay someone to > code) a change. Yes, you need to code a change. ALL programming languages provide this ability. Do it in the application, IMHO. Nothing should be in the database that is not critical to the storage of data; in this case, TZ is a *display* issue, not a storage issue. If all times are stored in UTC, then the application developer (the user) can choose to display or convert that time into whatever locale/TZ they wish (just as Drupal currently does, for instance) > What is our purpose? To end up in a textbook as the purest example of > date time implementation or to create a database that common people > would really want to use? IMHO, our purpose is not to provide timezone conversion in the database. It's to store it in a standardized, singular way, and let application developers do what they want with that data. This is the same reason we removed the silly zerofill arguments for integer data types. > I'd say that adding (non compulsory) TZ information to the datetime > field is going to be good for users. Depends on who you see as a "user". In my mind, a developer using drizzle is the user, not the end-user of the application running on drizzle. *Those* users (end-users) need to talk to the developer of the application, not to the developer of the database it is running on. Square pegs go in square holes. You don't send the toy back to the manufacturer to fix just because you want the round peg to go in the square hole. :) My 2 cents, Jay _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
