tag:blogger.com,1999:blog-3081576141653618753.post4384833704801148289..comments2024-03-12T14:14:59.653-07:00Comments on Two Piece Set: Solving Tough Problems: Timezones and DSTSusanhttp://www.blogger.com/profile/10553935900881505139noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-3081576141653618753.post-82873719800999257992007-10-28T10:11:00.000-07:002007-10-28T10:11:00.000-07:00it sounds like a project i've wanted to do for age...it sounds like a project i've wanted to do for ages. time zone handling in pims has always annoyed me: the biggest problem is that most pims seem to ignore the fact that people are a) smart and b) invariably locally situated. so if i am in EST, and i say i have a flight to the uk at 7pm followed by a 9am meeting (horrible combination though that may be), then I mean 7pm EST and 9am GMT. and i don't want to have to specify that, and i definitely don't want my bloody pim to assume that i mean 9am EST and then change that meeting to 4am EST when i tell my computer i'm now in GMT. that's the approach that a lot of pims use, and it's a hideous combination of sloppy programming, trying to be smarter than the user, and assuming that your user is stupid. there may be times when it's appropriate for users to have to actively engage with time zone changes in that manner -- notably scheduling conference calls, say, across multiple time zones -- but even in that it seems better to assume smart users as much as possible.<BR/><BR/>rant over. sorry about that. <BR/><BR/>jAnonymousnoreply@blogger.com