Let's say you have a timestamp that's during the DST offset. You have to take that offset into account when converting the time. Even if you're not current using an offset.

That means that while in November using a formula of GMT_time = (localtime - localoffset)localoffset = +02:00 will not work in July unless you calculate what the localoffset value is supposed to be on that date in July. Thus the formula becomes a little more complex. GMT_Time = (localtime + getOffset(localdate)). The function getOffset() would have to peform the calculation based on the matching localdate value corresponding to the localtime.

Trouble is there's no programmatic way to reliably convert that back into the localtime on that localdate unless you know the offset for precisely that period of time. If the region uses a formula, as the US does, it's reasonably simple. But if the region takes an 'optional' stance on it's handling you're in for a real set of headaches.

If you're wondering why anyone should care, think of a scenario. Here's one, you come to work one morning on time at 8:30 am localtime. If you're in Washington, DC during July this happens to be four hours off GMT. This is because DC is five hours behind GMT and is using a DST offset of one hour. That means you got to work at 4:30 GMT. Fast forward to the winter and that's 3:30 GMT. Let's say your database stores the time as GMT. This means the database would have something like "7/1/2003T04:30:00Z" during the summer and "11/1/2003T03:30:00Z" during the winter. If you were doing personnel reports you'd have to take those shifts into account when doing calculations. If, for example, you wanted to determine tardiness your offset becomes crucial. Run that report using the wrong offset and it makes you look either habitually late in the summer or some sort of early-bird-gets-the-worm freak all winter.

Thus you'd have to make sure that your calculations always took the relative offset into account. Either that or you'd have to store using local times. Trouble is, if you want to do any calculations across multiple zones you'd need to make sure you stored the correct local offset along with it. In the previous example this would mean storing "7/1/2003T08:30-04:00" and "11/1/2003T08:30-05:00". Then you'd just have to make sure not to use the offset when doing calculations against it unless you transposed them back to GMT. Sound good so far, right? Wrong again. If you had timestamps stored from different zones you'd need to make sure you properly tracked them as such. Thus your counterpart arriving for work in San Francisco would calculate as "7/1/2003T08:30:00-07:00" and likewise use an "-08:00" offset in November. The key here is you cannot depend on using the "overall" offset. Here in DC that means you can't just slap "-05:00" on timestamps during DST.

Frankly, I continue to be confounded about timestamps. It all sounds so simple but given the plethora of timezones and regional and seasonal offsets it becomes more complex than you might think.

Futher reading:

WorldlTime, W3CDTF and ISO-8601 specs