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
