I like this idea and given this is effectively what most operating systems do for their user reported system time, I'm surprised this approach isn't used more often.
The only issue I can see is when it comes to importing from other products (eg Wordpress) or exporting - the source or destination timezone would need to be taken into account and the the times updated accordingly. This however would be something the respective plugins would need to take into account, not Habari itself. On Wed, Nov 24, 2010 at 6:40 PM, Chris Meller <[email protected]> wrote: > So I was thinking about how to implement user timezone settings. In order to > display the timezone correctly for a user, we need to know what timezone it > was stored to the database with. Ordinarily this would be the global > blog-defined timezone, but I'm considering the merits of storing all dates in > the DB as UTC instead. > > If we store dates with the currently-defined blog setting, we run the risk of > confusing ourselves in the future, should the blog setting change. This is > particularly true for Daylight Saving Time changes, in which dates could end > up being an hour off twice a year. A post I saved at 11am could now show that > it was saved at 10am or 12pm, depending on shifts in the blog's timezone, > simply because it doesn't know what timezone it was originally saved under. > > If, however, we always store dates in the db as UTC, we have no such problem. > If you save a post at midnight (when converted to UTC), it's always midnight > UTC, regardless. The transformation into the desired timezone only happens on > display. > > So my question is: If we were to assume this and, using an update method, > batch change all current dates to UTC (based on the blog's timezone setting > at the time the upgrade ran), what problems do we forsee? > > Ideally, if my blog is set to EST, all the dates would get updated to UTC in > the database (ie: bumped ahead 5 hours), and HDT would be updated to know how > to display them properly. There are various code-related challenges, but for > the time being I'm looking solely at the "big picture" of things this would > throw into chaos. As long as HDT knows how to convert it on display, is there > really a problem? > > From a technical standpoint I think as long as we save all HDT objects to the > db using HDT->sql instead of HDT->int and ->sql converts it to UTC, we're > fine on that front. The harder part is going to be when we're loading data > from the DB, making sure that HDT knows it's UTC vs. data coming in in the > standard blog timestamp. > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/habari-dev -- Colin Seymour Blog: http://colinseymour.co.uk Tech Stuff: http://lildude.co.uk Barefoot Running: http://barefootrunner.co.uk IRC: lildude #habari -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
