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
Ugh, I had the start code outside of my Rsubmit and the stop code still inside my Rsubmit.
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;
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).
Is that repeatable or did it happen only once?
Someone (or something) might simply have reset the server's clock.
Ugh, I had the start code outside of my Rsubmit and the stop code still inside my Rsubmit.
@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.
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.
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.
Don't miss out on SAS Innovate - Register now for the FREE Livestream!
Can't make it to Vegas? No problem! Watch our general sessions LIVE or on-demand starting April 17th. Hear from SAS execs, best-selling author Adam Grant, Hot Ones host Sean Evans, top tech journalist Kara Swisher, AI expert Cassie Kozyrkov, and the mind-blowing dance crew iLuminate! Plus, get access to over 20 breakout sessions.
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.