Message in WAIT state after DELAY_TIMESTAMP is in the past

Question

The queue's view DELAY_TIMESTAMP column appears to have the correct time, but when compared to SYSTIMESTAMP, there's an unexpected five hour difference. After the message should have gone to the READY state, it is still in the WAIT state.
For example, a message is enqueued using DBMS_AQ.ENQUEUE with delay of 60 seconds. I wait till well after the message should be dequeued. The message is still in the queue despite attempting to dequeue it with DBMS_AQ.DEQUEUE. Here is what the query looks like.
select delay_timestamp, systimestamp , delay_timestamp - systimestamp
from AQ$THE_QUEUE;
DELAY_TIMESTAMP = 7/1/2009 8:23:05.769546 PM
SYSTIMESTAMP = 7/1/2009 9:06:23.944861 PM +00:00
DELAY_TIMESTAMP-SYSTIMESTAMP +00 04:16:41.824685
The difference should be negative because the time should have expired. However, it's positive, 5 hours less the time since it was enqueued.
This code worked fine until it was re-installed as part of dropping and creating the Oracle user. It works fine on Oracle XE and other Oracle EE databases. The problem is consistent with some change having been done either in Oracle or the Unix operating system. I don't have control over those systems and the administrator says nothing changed. Oracle has been stopped and started since the problem was noticed. The queue table was then dropped and recreated.
Do you have any idea as to what could cause the difference? It looks like a difference between GMT and CDT time zones. It may be related to the session time zone, but when I set my session time zone to +00:00 to match the server, it becomes a one-hour difference instead of a five-hour difference.
It is Oracle 10g 10.2.0.4.0.
Thank you...

Answer 1

Thanks for the reply.
Yes, the five hour difference seems too coincidental. An offset in seconds is supplied to ENQUEUE, not a date, but I suppose AQ could calculate a due date based on the session timezone, but why? I'd think session time zone would be for display purposes. The fact that it's behavior changed without changes to the client environments (both JCBC java clients and PL/SQL clients on different machines) with identical PL/SQL code suggests AQ is responding to some kind of server parameter, either Oracle or Unix. I just don't know what.