1) You're (possibly) assuming that both timestamps come from the same machine. They could be from two machines (Server timestamps a transaction start, client timestamps the end.) Clocks are not accurate, so the delta time is not correct.
2) Time A is before a DST change forward or back, Time B is after. Delta would be wrong by +/- 1 hour (assuming all other factors are tracking with accuracy.
3) Both times are taken on the same machine, but far enough apart that clock drift plays a factor.
4) Both times are taken on the same machine, but an ntptimesync cron job kicked off in between them and adjusted the system clock.
Timestamps are not affected by (or aware of) DST. In fact that's one reason why it's so easy to compute the time elapsed between two timestamps. From [0]:
$ ./timetool 1130647000
1130647000 = Sunday Oct 30, 2005 00:36 EDT
1130647600 = Sunday Oct 30, 2005 00:46 EDT
1130648200 = Sunday Oct 30, 2005 00:56 EDT
1130648800 = Sunday Oct 30, 2005 01:06 EDT
1130649400 = Sunday Oct 30, 2005 01:16 EDT
1130650000 = Sunday Oct 30, 2005 01:26 EDT
1130650600 = Sunday Oct 30, 2005 01:36 EDT
1130651200 = Sunday Oct 30, 2005 01:46 EDT
1130651800 = Sunday Oct 30, 2005 01:56 EDT
1130652400 = Sunday Oct 30, 2005 01:06 EST
1130653000 = Sunday Oct 30, 2005 01:16 EST
1130653600 = Sunday Oct 30, 2005 01:26 EST
1130654200 = Sunday Oct 30, 2005 01:36 EST
1130654800 = Sunday Oct 30, 2005 01:46 EST
1130655400 = Sunday Oct 30, 2005 01:56 EST
1130656000 = Sunday Oct 30, 2005 02:06 EST
1130656600 = Sunday Oct 30, 2005 02:16 EST
1130657200 = Sunday Oct 30, 2005 02:26 EST
$
So it's down to the accuracy (and synchronicity) of the clocks used to measure the timestamps: The difference between two timestamps is an accurate measure of the time elapsed (but see below), but that's probably only useful to you if the timestamps themselves are accurate.
However, leap seconds -- during which time passes, but the timestamps typically do not -- and numerical issues stemming from truncation and subtraction do have a systematic impact and reduce the accuracy of the difference. You can address the former for timestamps in the past by simply taking into account the leap seconds; you can address the latter by using higher resolution timestamps, ie. using millisecond timestamps if you need better-than-second-accuracy for the amount of time elapsed.
True, but that depends on what exactly you're reading as a timestamp.
Using localtime in perl for example (a very common method to read the system time) does not return a timestamp, but returns a formatted string (see: http://perldoc.perl.org/functions/localtime.html) that could easily be thrown off by a DST changeover.
#4 is why you really should be using ntpd(8): after syncronization, NTP will try to slew the clock if the difference is less than 128ms, step it if it's offset is between 128ms and 1000ms, and will exit with an error if the offset changes to be greater than 1000ms.
1) You're (possibly) assuming that both timestamps come from the same machine. They could be from two machines (Server timestamps a transaction start, client timestamps the end.) Clocks are not accurate, so the delta time is not correct.
2) Time A is before a DST change forward or back, Time B is after. Delta would be wrong by +/- 1 hour (assuming all other factors are tracking with accuracy.
3) Both times are taken on the same machine, but far enough apart that clock drift plays a factor.
4) Both times are taken on the same machine, but an ntptimesync cron job kicked off in between them and adjusted the system clock.