Here's the deal with timezones.
vBulletin doesn't correct for timezone changes. This means there are two ways to work around it, and both are incorrect.
1) Set system time to local (EST/PST, whatever) and tell vbulletin that system time is always -5, -8, or whatever. This fixes U.S. DST-abiding locations, as system time is automatically corrected for local DST effects, but when DST (daylight savings time) goes away soon, but has serious drawbacks. Anyone with a user timezone set to GMT will have timestamps off by an hour during the summer and fall. Anyone in the few U.S. locations that don't use DST will have similar problems, and anyone outside the U.S. in a location that doesn't abide by North American DST changes will have similar problems.
2) Set system time to GMT. Since vbulletin only handles static offsets (-5, -8, etc.), when DST changes, times for people in DST zones will be off by an hour.
I consider 2 to be better than 1, but if there's a concensus that nobody cares about correctness and the only thing that's important is unobtrusive correct time for most Americans, I can change it back.
Here's my problem. TFL used to use choice 1). I'm a bit psychotic with timezones and wanted my offset to be 0. Unfortunately, that means during the summer TFL time for me was off by an hour. I realize it's a royal pain in the butt to change timezone offsets twice a year, but consider that not everyone, even inside the U.S., uses daylight savings time. Also, DST doesn't apply the same all throughout the continents - think about the effect of imposing North American DST changes on someone in Brazil
"Spring Ahead" doesn't work too well when you're approaching the winter months in South America. If you want to see what a disaster DST is just for Australia and Tasmania, check out
http://www.dstc.qut.edu.au/DST/marg/daylight.html
The only way to fix this disaster is to hack up vbulletin, changing a database field in the process, and creating a zone for each potential combination of timezone and DST observance. And if you don't believe me, go to bladeforums right now and set your timezone offset to GMT. You'll notice it's an hour off.
Right now, for people in Eastern, Central, Mountain, or Pacific timezones, even though the displayed GMT offset is wrong, the time is correct. This was done (after a bit of confusion) to avoid having everyone's time become incorrect during the summer when nobody was likely to connect date changes with the disabling of DST correction. This "feature" will be going away in a week, and the offsets displayed by vbulletin will be universally correct. Until and unless a new vbulletin version has complete timezone functionality or I or someone else gets inspired to fix it, choices 1 and 2 are the only options.