An Idea Exchange for SAS software and services

Comments
by Respected Advisor
on ‎05-01-2013 07:05 AM

What's wrong with STIMER informat?  Seems like a waste of time to pursue that.

by PROC Star
on ‎05-01-2013 11:45 AM

Nothing is wrong with STIMER.

What was wrong with having all the existing time informats?

Nothing either.

Yet anydttme was a welcome addition, and the more universal, the better (within reasonable limits; The time formatting used in the log is standard and is well within these limits).

Why this doesn't work now it the real question imho.

by SAS Super FREQ
on ‎05-03-2013 10:23 AM

As I understand it, STIMER is used for reading elapsed times, such as how long it takes someone to run a race.  ANYDTTME is used to read the time of day, which is the number of seconds since midnight.  These are different quantities with different meanings.  For one thing, an elapsed time can have an hours field that is larger than 24.

When you say "read SAS log times," do you mean that you are parsing the SAS log in order to extract the processing time from the NOTES that SAS puts out?  Those times are elapsed times, so I would use STIMER.

by Contributor cov_derek
on ‎05-03-2013 11:26 AM

To further clarify Rick's statement: If you are reading the time provided by notes in a SAS log, processing this as a datetime value is incorrect, because using a datetime value implies that you are looking at time relative to seconds since midnight, Jan 1, 1960. If your time is 28:50:33 (28 hours, 50 minutes, 33 seconds), reading it as a datetime value would give you the value of 103833 seconds since midnight 1/1/1960, or a datetime of 4:50:33 AM, January 2, 1960. While the actual number of seconds is the same, the context is wrong.  The value in the SAS log has nothing to do with the date/time the program was run..

If you could take the date the program was run and combine it with the elapsed time in the log, the difference would be much more obvious. Say you ran your program at midnight May 2, 2013, and it finished in 28:50:33. If you were to read this as elapsed time (number of seconds), the value would still be 103833. However, reading this as a datetime value would give you 1683175833, which corresponds to 4:50:33 AM on May 3, 2013.


Hope this helps to clarify why the ANYDTTME. informat isn't used to parse times in the SAS log, and why it shouldn't be used for this purpose.

by PROC Star
on ‎05-16-2013 07:42 PM

Cov, I never mentioned datetimes, just times.

Rick, that's a valid point: elapsed vs clock, or relative vs absolute, but really we are still only counting seconds.

Whether it is since midnight or since a proc started makes little difference.

I must admit I never thought about a step that would last over 24 hours though it is of course possible.

It doesn't matter anyway, 25:01:01.23 is read fine by time informats.

So my request still stands valid as I see it: there is no reason time informats, especially the versatile ANYDTTME. (I can't check the next string atm, sorry), should read 25:01:01.23 fine and choke on 25:1:01.23.

But whatever, I am not going to defend this one further, it is not that important; It would just be nice that the read-all time informat could read perfectly simple and valid strings imho. If everybody disagrees that's fine.

by Regular Contributor
on ‎05-26-2015 04:12 PM

I agree: this is a non-trivial task.

check this page for code on this task.

http://www.sascommunity.org/wiki/Reading_job_logs

Ron Fehd  logging maven

Idea Statuses
Top Liked Authors