4 ms·

It isn't? Can you explain that in a bit more detail?

by SCdF 14y ago

brk 14y ago
Some examples that come to mind: 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.
- icehawk 14y ago
  #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.
- deleted 14y ago
  [deleted]
- morsch 14y ago
  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. [0] http://www.unix.com/unix-dummies-questions-answers/18754-timestamp-confusion-daylight-saving-time.html http://www.unix.com/unix-dummies-questions-answers/18754-tim...
  - brk 14y ago
    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 http://perldoc.perl.org/functions/localtime.html) that could easily be thrown off by a DST changeover.

It isn't? Can you explain that in a bit more detail?

by SCdF 14y ago

It isn't? Can you explain that in a bit more detail?

brk 14y ago

Some examples that come to mind: 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.

icehawk 14y ago
#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.
deleted 14y ago
[deleted]
morsch 14y ago
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. [0] http://www.unix.com/unix-dummies-questions-answers/18754-timestamp-confusion-daylight-saving-time.html http://www.unix.com/unix-dummies-questions-answers/18754-tim...
- brk 14y ago
  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 http://perldoc.perl.org/functions/localtime.html) that could easily be thrown off by a DST changeover.