www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Counting time difference.

reply holo <holosian gmail.com> writes:
Hello

I'm trying to count time difference to count time for how long 
instance is running. Here is how am i doing it:


import std.stdio, sigv4, kxml.xml, awsxml;
import std.datetime;
import std.string;



void main()
{
     SigV4 req = new SigV4;
     IfResult result = req.go;
     AwsXml instancesData = new AwsXml(result.retResult);
     auto instsData =  instancesData.getInstancesData;


     foreach(instData; instsData)
     {



         auto currentTime = Clock.currTime();
    //     auto currentStrTime = 
currentTime.toISOExtString().split(".")[0];
    //     auto currTime = 
SysTime.fromISOExtString(currentStrTime);

         auto launchStrTime = instData.instanceLaunchTime;
         auto launchTime = SysTime.fromISOExtString(launchStrTime);

         auto diff = currentTime - launchTime;

         auto zagadka = launchTime + diff;




         writeln(instData.instanceId ~ " " ~ instData.instanceName 
~ " " ~ instData.instanceState ~ " " ~ 
instData.instanceLaunchTime ~ " " ~ instData.instanceReason);
         writeln(launchTime);
         writeln(currentTime);
         writeln(diff);
         writeln(zagadka);
     }
}

but the results do not match (launchTime + diff != currentTime)


...

2015-Mar-17 14:32:24Z
2016-Feb-03 23:21:41.2374511
46 weeks, 1 day, 7 hours, 49 minutes, 17 secs, 237 ms, 451 μs, 
and 1 hnsec
2016-Feb-03 22:21:41.2374511Z


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.

//holo
Feb 03 2016
next sibling parent reply sigod <sigod.mail gmail.com> writes:
On Wednesday, 3 February 2016 at 22:27:07 UTC, holo 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.


Try using `Clock.currTime(UTC())`. And make sure all instances 
produce timezone independent timestamps.
Feb 03 2016
parent holo <holosian gmail.com> writes:
On Wednesday, 3 February 2016 at 22:45:03 UTC, sigod wrote:

 On Wednesday, 3 February 2016 at 22:27:07 UTC, holo 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.


 Try using `Clock.currTime(UTC())`. And make sure all instances 
 produce timezone independent timestamps.


Thank you, now i see that AWS is getting back Time in UTC so that 
solved problem.

 Jonathan M Davis

like i wrote above using UTC time helped me. Thank you for 
information about that monotonic clock will check it too for 
learning purpose.

//holo
Feb 04 2016
prev sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
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
Feb 03 2016