topic Re: datetime function - odd results in SAS Programming

datetime function - odd results

buechler66 — Wed, 05 Oct 2016 20:32:53 GMT

I run the same code at the beginning of my program and at the end. Basically I want a datetime stamp of when it starts and one for when it ends. I'm getting odd results tho. The datetime at the end of my program is actually earlier then the datetime at the beginning of my program. What am I missing here?

4    /*  Datetime stamp of program start */
5        data _null_;
6            dt_stamp = DATETIME();
7            PUT 'Progam Started: ' dt_stamp datetime20.;
8        run;

Progam Started:   05OCT2016:15:37:25
NOTE: DATA statement used (Total process time):
      real time           0.03 seconds
      user cpu time       0.00 seconds
      system cpu time     0.04 seconds
      memory              179.07k
      OS Memory           7556.00k
      Timestamp           10/05/2016 03:37:24 PM

987   /*  Datetime stamp of program stop */
988   data _null_;
989       dt_stamp = DATETIME();
990       PUT 'Progam Stopped: ' dt_stamp datetime20.;
991   run;

Progam Stopped:   05OCT2016:15:19:34
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.00 seconds

Re: datetime function - odd results

JediApprentice — Wed, 05 Oct 2016 21:19:00 GMT

That is really strange. Maybe try an alternative way with the dhms function and see if you get different results:

data _null_;
  day=date();
  time=time();
  dt_stamp=dhms(day,0,0,time);
  PUT 'Progam Started: ' dt_stamp datetime.;
run;

data _null_;
  day=date();
  time=time();
  dt_stamp=dhms(day,0,0,time);
  PUT 'Progam Stopped: ' dt_stamp datetime.;
run;

Re: datetime function - odd results

Patrick — Wed, 05 Oct 2016 23:06:17 GMT

I believe datetime() queries the servers internal clock so what you observe shouldn't be possible. Are you 100% sure that the "stop time" code executed after the "start time" code?

The only far fetched idea I currently have is that your code runs on a grid, that the two code blocks you've posted ran on different nodes, and that the clocks on the nodes are not in sync (which also shouldn't happen).

Re: datetime function - odd results

Kurt_Bremser — Thu, 06 Oct 2016 06:01:48 GMT

Is that repeatable or did it happen only once?

Someone (or something) might simply have reset the server's clock.

Re: datetime function - odd results

buechler66 — Wed, 12 Oct 2016 19:52:08 GMT

Ugh, I had the start code outside of my Rsubmit and the stop code still inside my Rsubmit.

Re: datetime function - odd results

Kurt_Bremser — Thu, 13 Oct 2016 06:16:12 GMT

@buechler66 wrote:

Ugh, I had the start code outside of my Rsubmit and the stop code still inside my Rsubmit.

That means you still have a big issue. All your hosts should be connected to a NTP service, so their clocks are synchronized. Some SAS metadata operations do not work if client and server are more than a few seconds apart.

Re: datetime function - odd results

buechler66 — Thu, 13 Oct 2016 11:19:57 GMT

That is good to know. Can you give me an example of such a SAS process
that would be effected or a link to any docs?

Thanks again.

##- Please type your reply above this line. Simple formatting, no
attachments. -##

Sent from mobile

Re: datetime function - odd results

Kurt_Bremser — Thu, 13 Oct 2016 11:29:45 GMT

Saving an Enterprise Guide project to metadata causes issues (at least with EG 4.3/SAS 9.2) when the clocks of server and client are not within a few seconds. The webdav server then obviously balks at the timestamps.

Re: datetime function - odd results

buechler66 — Thu, 13 Oct 2016 11:43:22 GMT

Thanks very much. Also, if anyone else knows of docs or examples that would be great. I will take this concern to our admits

At least one of our servers is on a different Timezone (-1 hour). Would this also contribute to the same type of issues?

Re: datetime function - odd results

Kurt_Bremser — Thu, 13 Oct 2016 12:04:30 GMT

Timezones should not be a problem. Computers keep their internal clocks in UTC, and use the timezone for display and input purposes.

This of course means that timestamps taken "visually" from remote hosts need to be corrected for timezone offset.