It's a bad idea to do so, and should be fixed. The time you are saving is a culture-specific format, it is a text, something the computer does not calculate with.
A DateTime in a computer is a floating point. The integer-part counts the days passed since the epoch (start of counting of days, often 1/1/1900), the decimal part represents the time, in ticks. They are not two separate facts - and should be modelled as a single field, of the DateTime-datatype. The computer can easily calculate with those.
Breaking the date and time into separate fields is as usefull as using a separate field for the day, month, year, hour, minute and second. If they represent a single atomic fact, than that is how it should be modelled.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
It's interesting that the Date type in Oracle while handled as a single entity but is stored internally as seven bytes. One byte each for year, month, day, hour minute, second and fraction of a second.
It's a space waster, but oh so fast to calculate with.
Timestamp on the other hand is stored as a floating point to save space.
You could try and merge DATE_CREATED and TIME_CREATED to get a DATETIME value then you could use between.
Something like (most likely will not work as written):
(Date_Created + Time_Created) BETWEEN @startdatetime AND @enddatetime
Just throw the exception.
There is no reason, I can think of, that you should need to catch an exception from a stored procedure.
Throwing the exception will allow the developer to have an error message and pursue fixing the error.
“That which can be asserted without evidence, can be dismissed without evidence.”