As APC correctly pointed out, your start_date column looks like TIMESTAMP, but it could be TIMESTAMP with a local TIMEZONE or TIMESTAMP with a data type of TIMEZONE. This can affect any queries you made to the data if your database server was in a different time zone for yourself. However, letβs keep it simple and suppose you are in the same time zone as your server. First, to give you confidence, make sure start_date is a TIMESTAMP data type.
Use the SQLPlus DESCRIBE command (or equivalent in your IDE) to verify that this column is a TIMESTAMP data type.
eg
DESCRIBE mytable
Must inform:
Name Null? Type ----------- ----- ------------ NAME VARHAR2(20) START_DATE TIMESTAMP
If it is listed as Type = TIMESTAMP, you can query for date ranges with a simple TO_TIMESTAMP date conversion that does not require an argument (or image).
We use TO_TIMESTAMP so that the optimizer takes into account any index in the START_DATE column. APC's response also noted that a function-based index can be created in this column, and this will affect the SQL predicate, but we cannot comment on this in this query. If you want to know how to determine which indexes were applied to the table, send another question and we can answer it separately.
So, suppose there is an index in start_date, which is a TIMESTAMP data type, and you want the optimizer to consider it, your SQL would be:
select * from mytable where start_date between to_timestamp('15-JAN-10') AND to_timestamp('17-JAN-10')+.9999999
+. 999999999 is very close, but not quite 1, so the 17-JAN-10 conversion will be as close to midnight as possible on this day, so you are requesting a return of both lines.
The database will show BETWEEN: from 15-JAN-10 from 00: 00: 00: 0000000 to 17-JAN-10 23: 59: 59: 99999 and therefore will include all dates from the 15th, 16th and 17th January 2010, regardless of the time component of the timestamp.
Hope this helps.
Dazzer
Darren Atkinson Mar 03 2018-10-03T00: 00Z
source share