10-05-2016 04:32 PM - edited 10-05-2016 04:32 PM
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
10-05-2016 04:59 PM - edited 10-05-2016 05:19 PM
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;
10-05-2016 07:06 PM
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).
10-06-2016 02:01 AM
Is that repeatable or did it happen only once?
Someone (or something) might simply have reset the server's clock.
10-13-2016 02:16 AM
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.
10-13-2016 07:19 AM
10-13-2016 07:29 AM
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.
10-13-2016 07:43 AM
10-13-2016 08:04 AM
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.
Need further help from the community? Please ask a new question.