Making date and time sense from the SQL Server Agent job history table

3 thoughts on “Making date and time sense from the SQL Server Agent job history table”

  1. What were they thinking? The mind boggles. This is even worse than storing the date and time as strings, as it’s one conversion further from the truth.

  2. Well I suppose its a legacy design issue from the days of Sybase or something like that. Perhaps they never had a DATETIME data type then the next best would be two 32-bit integers. I would have thought though that they would have put a new table down and created a view for backwards compatibility or something. They seem to have done it for other tables.

  3. It’s been like this for many versions, but that’s no excuse. There are far better ways to express times, even using a string, than it’s using. The duration is stored in the same way. Have fun working out how long a job ran for…

    Frankly, MSDB is a wonderful example of a terribly designed database. Don’t even get me started on sysjobschedules.

    I had three UDFs that I used to use to turn the data into something actually usable.

Comments are closed.