cron Will Respond To Changes in Time
If you adjust the system time while cron is running, cron will notice and attempt to compensate. If time moved backwards, cron will stop running jobs and wait for the clock to advance back to where cron run the last job. If time moved forwards, cron will try to catch up. It will click though each minute continuously until it has run all of the jobs scheduled during the skipped time duration. If you are simply tweaking the system clock because it was off a few seconds, this is perfect. But if the time is a year off, it will probably not be a good thing. For large adjustments to the clock you should kill and restart cron.

cron Will Respond To Daylight Saving Changes
Suppose I have a job scheduled to run at 2:15 Sunday morning. When we "spring ahead", there won't be a 2:15. cron will note that we "sprung ahead" by 60 minutes, so it will add 60 minutes to my job time getting 3:15. It will run the job at 3:15...unless the job was already scheduled to run at both 2:15 and 3:15. In that case, my job will run once at 3:15.

Later in the year, we "fall back". On that Sunday, it will be 2:15 twice. My job will only run at the first 2:15. If my job is scheduled to run at 15 minutes after every hour via the explicit use of an asterisk in the hour field my job will run at both 2:15's. This is not true if I use a range or a list of hours to run. Only jobs with an asterisk for the hour field run at both 2:15's.

cron Has Its Own Timezone
If I schedule my job for 2:15 in the morning, cron will run it when it thinks that the time is 2:15. cron is closely related to the "at" command. If I schedule at job via "at" to run at 2:15, my TZ variable is inspected and the job will run at my 2:15. But cron does not work that way.