Instead of relying on the TZ environment variable, you should set your default timezone either using the ini setting date.timezone or with the date_default_timezone_set. See http://www.php.net for more info.
As for what information to put in the database, I'd say it depends on what the schedule looks like over time. If every dj always is on air during the same time every day, I'd just keep dj_id, start_time, end_time as time datatype in the db. If it varies from day to day, but stays the same from week to week, I'd also add a weekday field. If there is no pattern to air times, I'd go back to storing only start and end, but instead of using a time datatype, I'd use datetime.
After that it's pretty straight forward to retrieve the current dj. Example assuming the schedule is the same from week to week
$now = date('H:m:i');
$weekday = date('N');
$qry = 'SELECT dj.name, img, show.name AS show_name
FROM dj
INNER JOIN show ON show.dj_id = dj.id
WHERE weekday = '.$weekday." AND '$now' BETWEEN start_time AND end_time";
Assuming the two tables are dj and show, where dj contains all the djs, and show contains the radio shows, including the id of the dj hosting it.
From an administrative viewpoint, there may still be a point to storing datetimes, rather than just times as above. Otherwise, it's not possible to make changes more than one week ahead of time. If you do go with this approach, remove the start/end times from the show table and create a new table, air_time, containing id, show_id, start_time, end_time (which are now datetime types). This way you still only need to keep show info in one single place, but there will be on row in air_time for each time the show is airing.
And to make it easier to administrate this, you could go with something along the lines of letting the user specify start and end times, start and end dates and have checkboxes for weekdays. Then you let your script figure out what datetimes that correspond to and insert one row for each.