datetime function - odd results

[buechler66]

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

[JediApprentice]

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;

[Patrick]

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).

[Kurt_Bremser]

Is that repeatable or did it happen only once?

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

[buechler66 · Accepted solution]

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

[Kurt_Bremser]

---

@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.

[buechler66]

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

[Kurt_Bremser]

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.

[buechler66]

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?

[Kurt_Bremser]

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.