First of all: Why?
Secondly: this is RAC, so you should be able to shut down one instance at a time, without shutting the database, so I don't see the issue.
Also, please be aware (you, like most here, don't mention a version) in 10g and higher the GSD layer picks up the time from the system clock, the listener from GSD and the database from the listener,
so yes, you would also need to shutdown the listener and the GSD.
Again, per node, so there shouldn't be any issue.
Senior Oracle DBA
you might want to check this doc:
How to diagnose wrong time ( SYSDATE and SYSTIMESTAMP) after DST change , server reboot , database restart or installation when connecting to a database on an Unix server (Doc ID 1627439.1)
It will give you a detailed overview on what to check and wether you have to restart the DBs.
In a short: A Unix process keeps the environment settings when it was started. If your os users has a TZ setting with a fixed value e.g. UTC+1 and due to daylight saving you now have UTC+2, then your db, listeners,... won't get that change until you configure it on the os environment and then restart the processes.
If you however have a timezone that does include the dailylight savings, eg. "TZ=Europe/Berlin" then you have to do nothing. Your os should handle setting the 1 hour jump via NTP and your db will be ok without restart.
You do not have to take down anything to change the time. My servers automatically change their time without me stopping anything. The Oracle software can handle the time change just fine.
Note that some applications, not all, have time sensitivity. This is normally an issue in the Fall when the time goes backwards one hour. At 1:59am, the time is stored in the database. At 2:01 am, the time being stored is now 1:01am. The application may think the record in the table is 58 minutes earlier when it was 2 minutes later. If this will cause problems with the application, then shutdown the application for one hour. But the database doesn't need to go down.