cron operates on 'wall clock time' i.e. displayed, hence but it needs to know about which TZ you have in effect. That's why you need to restart it when you change TZ value.
Your job would run twice on changeover from daylight savings time to standard time, unless you have coded some stuff to run that job only once on any given date...
Your job would not run on changeover from standard to daylight savings.
I suggest you read the man page for cron.
When the TZ environment variable is changed, either with the chtz
command, a Web-based System Manager application, or through SMIT, the
cron daemon must be restarted. This enables the cron daemon to use the
correct time zone and summer time change information for the new TZ
environment variable.
Notes:
1 If you have a job scheduled to run between 1:00 AM and 2:00 AM on
the day your time zone changes from daylight saving time to
standard time your job will run twice.
2 If you have a job scheduled to run between 2:01 AM and 2:59 AM on
the day your time zone changes from standard time to day light
savings time your job will not run. You can change the time these
jobs run, run them manually, or wait until the following day to
run them. The cron daemon does not need to be stopped. However, if
changes are made to the TZ environment variable, kill the current
cron daemon so that it automatically respawns and recognizes the
new TZ setting.
The reason that sar 'misses' 2:00 to 2:59 at the end of March is because it displays a stored GMT time and that 'displaying' also adheres to the TZ rules. You would also see the 2:00 to 2:59 timeframe twice at the end of October I guess.
Same deal for a sar which happens to be running when the DST changeover occurs.
HTH,
p5wizard