Daylight Savings time, and how dates are stored internally and displayed

Question

This is probably a question that appears here annually, but I couldn't really find clear answers, so I'll try asking this in my own words:
I'm in the Eastern timezone, and this Sunday, we'll be turning our clocks back an hour at 2:00 AM. That means that accordign to us humans, the time 1:30 AM will occur twice on Sunday.
I've got an Oracle application that runs every 5 minutes around the clock, and it selects records from a certain table whose updated timestamp (TIMESTAMP(6)) is greater than SYSDATE - 5/1440, meaning any record that was updated in the last 5 minutes. Will we have a problem with some records being processed twice on Sunday morning? I'm theorizing that everything will be OK, that internally, Oracle stores DATE fields using something like an epoch which then gets interpreted when we display them. An epoch value will continue to grow each second no matter what “time” it is according to the U.S. Congress.
A simpler way to look at the question might be as follows:
If you store SYSDATE in a DATE column in row “X” at 1:30 AM before the time change, and you store sysdate in row “Y” exactly one hour later, will Oracle say that X’s timestamp is 60 minutes less than Y’s timestamp? All fields that are related to my particular situation are either DATE or TIMESTAMP(6).
We use 11g.

Answer 1

>
That settles that! Thank you! My theory was wrong! I appreciate the help.
>
You may think it settles that but, sorry to burst your bubble, that doesn't really settle much of anything.
One thing that was settled is the answer to this question
>
But are they talking about what you can EXTRACT and DISPLAY from the field or what is actually STORED internally?
>
which is, as Mark stated, they are talking about what is stored internally.
The other thing that was settled is that you will pull the same, or mostly the same, data twice during that one hour. I say 'mostly the same' because of the major flaw your extraction method has to begin with.
>
If you store SYSDATE in a DATE column in row “X” at 1:30 AM before the time change, and you store sysdate in row “Y” exactly one hour later, will Oracle say that X’s timestamp is 60 minutes less than Y’s timestamp?
>
No - they will have the same time since 'one hour later' would have been 2:30 AM but the clock was turned back an hour so is again 1:30 AM. So the second time your job runs for 5 minutes at 1:30 AM it will pull both the original 1:30 AM data AND the data inserted an hour later.
And Oracle will say that data stored in row "Z" exactly 45 minutes later than "X" at 1:30 AM will have a date of 1:15 AM and will appear to have been stored earlier.
Your method of extracting data is seriously flawed to begin with so the daylight savings time issue is the least of your problems. The reason is related to the answer to this question you asked
>
do people avoid using DATE and TIMESTAMP datatypes because they are too simple?
>
That method isn't reliable - that is why people avoid using a date/timestamp value for pulling data. And the more often you pull data the worse the problems will be.
>
I've got an Oracle application that runs every 5 minutes around the clock, and it selects records from a certain table whose updated timestamp (TIMESTAMP(6)) is greater than SYSDATE - 5/1440, meaning any record that was updated in the last 5 minutes
>
No - it doesn't do that at all, at least not reliably. And THAT is the why your method is seriously flawed.
The reason is that the value that you use for that DATE or TIMESTAMP column (e.g. SYSDATE) is assigned BEFORE the transaction is committed. But your code that extracts the data is only pulling data for values that HAVE BEEN committed.
1. A transaction begins at 11:59 AM and performs an INSERT of one (or any number) of records. The value of SYSDATE used is 11:59 AM.
2. The transaction is COMMITTED at 12:03 AM.
3. Your job, which runs every five minutes pulls data for the period 11:55:00 AM to 11:59:59 AM. This job will NOT see the records inserted in step #1 because they had not been committed when your job query began execution - read consistency
4. Your job next pulls data for the period 12:00:00 AM to 12:04:59 AM. This job will also NOT see the records inserted in step #1 because the SYSDATE value used was 11:59 AM which is BEFORE this jobs time range.
You have one or ANY NUMBER of records that ARE NEVER PULLED!
That is why people don't (or shouldn't) use DATE/TIMESTAMP values for pulling data. If you only pull data once per day (e.g. after midnight to get 'yesterdays' data) then the only data you will miss is for data where the transaction began before midnight but the commit happened after midnight. Some environments have no, or very little, activity at that time of night and so may never have a 'missing data' problem.
Creating your tables with ROW DEPENDENCIES will store an SCN at the row level (at a cost of about 6 bytes per row) and you can use the commit SCN to pull data.
Just another caveat though - either of those approaches will still NEVER detect rows that have been deleted. So if you need those you need yet a different approach such as using a materialized view log that captures ALL changes.