On 8/26/08, Josh Berkus <[EMAIL PROTECTED]> wrote: > > Arjen, > > So how do you feel about the idea of scrapping timezones from the db >> altogether? >> (talking technical/practical merit, of course it's sad tossing out lots of >> work ;-) >> > > Well, the real question is how well does it work now? You can sink an > infinite amount of work into fixing up a conceptually flawed codebase. > > As others on this list do, I think the sensible thing is to store > timestamps in UTC and display them in the client's current time zone unless > the user explicitly says otherwise with an "at time zone" clause. > > I think it's also a good idea to accept timestamps at a particular time > zone, but convert them to UTC before storage.
I think we (developers, dbas, etc) have to stop thinking about time as we experience it, and accept that timezones are a presentation issue. It makes things a whole lot easier if you separate the functionality of time with the presentation of it -- it also helps when dealing with folks who code in times instead of using database functions for time -- which ends up having problems when the web/application servers are not time sync'd (or in particularly poor programming, when they're in different time zones). So, if you want to retrieve or store a time (including "now"), that's a database function. If you want to display a time, that's a presentation layer function. (there are cases in which I'd be OK with application code determining time, but that's only for queries that otherwise would take forever. If you start with having one centralized definitive time server (which I'm making the database here for simplification) it will lead to much less confusion in the long run). -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
