Counting time difference.

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, February 03, 2016 22:27:07 holo via Digitalmars-d-learn wrote:
> When i start same program on server in different timezone
> difference is much higher (more than hour). Why it is happening?
> Timezones shouldnt have influence on such equation.

You're probably getting problems due to the fact that LocalTime does not put
the timezone on the end of the ISO extended string like it should. Per the
standard, an ISO Extended string without the timezone on the end is
considered to be local time, so reading such strings in as local time is
what fromISOExtString should be doing, but I made the mistake of also having
it output the string without the timezone on it for local time (which is
technically correct but error-prone). Until that gets fixed, you probably
should never use toISOExtString on a SysTime that's has LocalTime for its
TimeZone (which is the default). Either use Clock.currTime(UTC()) to get the
time in UTC, or do st.toUTC().toISOExtString() to convert the SysTime to UTC
before converting it to a string.

Now, that being said, you never actually use the wall clock time for timing
anyway. The wall clock gets skewed all the time for time adjustments, and
stuff like DST screws life up. SysTime does hold its time internally in UTC,
which reduces the problem with regards to time zones and DST, but there's
still no guarantee that what the computer considers the wall clock time is
going to be consistent. It's useful for any time you need a timestamp (and
aside from DST is probably no more than a few seconds off), but using for it
for precise timing is very error-prone.

If you want to time stuff, then you should use the system's monotonic clock,
which means using core.time.MonoTime. e.g.

    auto start = MonoTime.currTime;
    // do stuff
    Duration diff = MonoTime.currTime - start;

The monotonic clock moves forward by a fixed number of ticks per second,
never moves backwards, and doesn't care one whit what the timezone is or how
its ticks correspond to the wall clock time. It's just counting how many
clock ticks have passed. So, it's exactly what you want to use for timing
stuff. So, try using MonoTime instead and see how well that works for you
(though it's still not likely to match the difference between the wall clock
time when you start and when you end, precisely because the wall clock time
is constantly shifting, even if it's only by a little; though if you fix the
issue with toISOExtString and local time in your code, then it should be
fairly close).

- Jonathan M Davis