www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - time difference - beautify my code

reply "dd0s" <oggs gmx.at> writes:
i got a date t described in seconds from 1.1.1970, and i want to 
check if the current time is further than 12 hours from the given 
time t. the following code works but it's super ugly =S

please give me some ideas how to make this code nicer :)

   private static bool sessionIsCurrent(long t)
   {
     DateTime dateTime = DateTime(1970, 1, 1) + 
dur!"msecs"(t*1000);
     DateTime curTime = DateTime() + 
dur!"hnsecs"(Clock.currStdTime());
     return (curTime - dateTime) < dur!"msecs"(1000*60*60*12);
   }

thx for your effort
Jul 02 2015
next sibling parent reply "anonymous" <anonymous example.com> writes:
On Thursday, 2 July 2015 at 19:03:49 UTC, dd0s wrote:

 i got a date t described in seconds from 1.1.1970,


I.e., you have a unix timestamp.


 and i want to check if the current time is further than 12 
 hours from the given time t. the following code works but it's 
 super ugly =S

 please give me some ideas how to make this code nicer :)

   private static bool sessionIsCurrent(long t)
   {
     DateTime dateTime = DateTime(1970, 1, 1) + 
 dur!"msecs"(t*1000);


dur!"msecs"(t*1000) -> dur!"seconds(t) -> t.seconds

Better yet (`to` from std.conv):
auto dateTime = SysTime(unixTimeToStdTime(t)).to!DateTime;

Or just go with SysTime instead of DateTime:
auto dateTime = SysTime(unixTimeToStdTime(t));


     DateTime curTime = DateTime() + 
 dur!"hnsecs"(Clock.currStdTime());


Like above, use `to` to convert from SysTime to DateTime:
auto curTime = Clock.currTime.to!DateTime;

or just use a SysTime:
SysTime curTime = Clock.currTime;


     return (curTime - dateTime) < dur!"msecs"(1000*60*60*12);


Like above, dur!"msecs"(1000*60*60*12) -> dur!"seconds"(60*60*12) 
-> dur!"minutes"(60*12) -> dur!"hours"(12) -> 12.hours


   }


Putting it all together, removing the now pointless variable 
curTime, adding a pinch of immutable for the taste:

private static bool sessionIsCurrent(long t)
{
     immutable dateTime = SysTime(unixTimeToStdTime(t));
     return (Clock.currTime - dateTime) < 12.hours;
}

Final thoughts:

You may want to check that t is not in the future.

I'm not 100% sure if switching from DateTime to SysTime fixes a 
bug, introduces a bug, or doesn't make any difference. As far as 
I can tell, it doesn't change anything, because you're not 
dealing with different time zones.
Jul 02 2015
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, July 02, 2015 19:42:57 anonymous via Digitalmars-d-learn wrote:

 On Thursday, 2 July 2015 at 19:03:49 UTC, dd0s wrote:

 i got a date t described in seconds from 1.1.1970,


 
 I.e., you have a unix timestamp.
 

 and i want to check if the current time is further than 12 
 hours from the given time t. the following code works but it's 
 super ugly =S





 private static bool sessionIsCurrent(long t)
 {
      immutable dateTime = SysTime(unixTimeToStdTime(t));
      return (Clock.currTime - dateTime) < 12.hours;
 }


I'm not sure if immutable works with SysTime. It didn't used to (due to
issues with the compiler, not the type itself). Also, it's probably not a
good idea to sue the name dateTime for a variable of type SysTime.


 You may want to check that t is not in the future.


Depending on what exactly the OP is looking for, they may want to do
something more like

private static bool sessionIsCurrent(long t)
{
     auto st = SysTime(unixTimeToStdTime(t));
     return abs(Clock.currTime - dateTime) < 12.hours;
}

With what you have, it'll return true not only if the given time was less
than 12 hours ago, but it will return true if it's at any point in the
future. Now, that may be exactly what the OP wants, but checking if "the
current time is further than 12 hours from the given time" could be taken
to mean that if it's more than 12 hours past the current time, the function
shouldn't return true. Only the OP knows exactly what they meant though.


 I'm not 100% sure if switching from DateTime to SysTime fixes a 
 bug, introduces a bug, or doesn't make any difference. As far as 
 I can tell, it doesn't change anything, because you're not 
 dealing with different time zones.


When you convert to a DateTime from a SysTime, you're getting the equivalent
year-date-month and hour-minute-second that the SysTime represents in the
time zone that it's set to (LocalTime by default). So, you lose subsecond
precision (which likely wouldn't matter in this case), and you lose the time
zone, so you do potentially have to take that into account when converting
back, but if everything is in LocalTime, that's usually not a problem. The
main problem would be if the time in question were during a DST switch, in
which case, you might not get the same SysTime back (even ignoring the
fractional seconds).

So, in general, while it can be useful to convert a SysTime to a DateTime
(especially if you want all of the units split out), it's generally better
not to convert a DateTime to a SysTime unless you actually need to
(primarily because DST screws with things).

- Jonathan M Davis
Jul 03 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, July 02, 2015 19:03:48 dd0s via Digitalmars-d-learn wrote:

 i got a date t described in seconds from 1.1.1970, and i want to
 check if the current time is further than 12 hours from the given
 time t. the following code works but it's super ugly =S

 please give me some ideas how to make this code nicer :)

    private static bool sessionIsCurrent(long t)
    {
      DateTime dateTime = DateTime(1970, 1, 1) +
 dur!"msecs"(t*1000);
      DateTime curTime = DateTime() +
 dur!"hnsecs"(Clock.currStdTime());
      return (curTime - dateTime) < dur!"msecs"(1000*60*60*12);
    }

 thx for your effort


Well, as anonymous pointed out, you probably want something more like

return Clock.currTime() - SysTime(unixTimeToStdTime(t)) < hours(12);

And if you use DateTime the way you are in your current code, it'll treat
that time as if it were in local time, whereas unix time is in UTC. So,
you'd be off by the difference between UTC and your local time zone.

In addition, even if you want to use dur instead of the aliases, I would
point out that code like dur!"msecs"(t * 1000) doesn't make a lot of sense,
because you can just do dur!"seconds"(t) - or you can use the aliases (which
have the same names as the string template parameters) - e.g. seconds(t)
or hours(12). dur is required for generic code, but for non-generic code,
it's obviously up to you whether to use dur or the aliases, but most folks
prefer the aliases.

- Jonathan M Davis
Jul 03 2015
parent "dd0s" <oggs gmx.at> writes:
cool, thx for the detailed explanation guys!
Jul 03 2015