The picture you posted is not a table by definition. It's got duplicate rows! You have no key or constraints. The strings you posted are not how we represent a time value in SQL (or any other ISO standard I know) Based on nothing you posted, Did you know that SQL has a TIME(n) data type? Why did you fail to use it and go for a 1950s COBOL kludge with strings instead?
CREATE TABLE Foobar
(begin_time TIME(0) NOT NULL DEFAULT '00:00:00',
end_time TIME(0) NOT NULL PRIMARY KEY, --- keys are not optional
CHECK (begin_time < end_time),--- my guess
>> Heh... seriously, Joe. You have to understand when people are just posting an example. You also have to get over things like the data they posted because this junk happens all the time in real life and they've been tasked to use it. <<
Remember that I've been at this for over 30 years. The fact that bad SQL occurs "all the time." is a little like saying we need to learn to live with the plague instead of teaching people to wash their hands and flush toilets. I can't find the exact quote immediately, but is from Frank Lloyd Wright; "if you want to have good architecture, then you have to be willing to point out bad architecture". This is a principle that applies in spades with computer code.
>> Even the job history in MSDB.dbo.sysjobhistory uses the miserable format for time that the OP is contending with and the OP can't do anything about that, either. <<
Yes, vendors have a lot of bad code in their sample databases. Some of that is deliberate (a sample databases trying to be all things to all people and give examples of all possible techniques), but a lot of it is just denormalized ignorance. In this example I'm not talking that anything fancy. Why do you want to give the poster the idea that what he's doing is just fine and really good database schema? Since I make a lot of my consulting money fixing disasters, I'm the one that should be cheering for bad programmers like this!
Please post DDL and follow ANSI/ISO standards when asking for help.