I do agree with Ronald that there are cases when you want the scheduled event to run on the time you specify thus including a DST correction. Mostly because several systems are doing stuff in a certain order the are not synchronized and the event is estimated to be finished in a certain time. See this as a poor man's sync.
However if you do so you should not schedule such an event between 02:00 and 03:00. 02:00 itself cannot be used, 01:59 can. 03:00 cannot be used, 03:01 can.
So a checkbox (boolean) on scheduled events to fix for DST and a modeler GUI check to disallow the 02:00-03:00 time range could solve the issue.
I think Jan Doggen exactly points out the problem when including DST, its way more complex to handle the cases when the shift takes place right (because in that case certain timestamps exist twice, and others not at all) then it is to detect whether you are in summer or winter time and just shift the event (or, if applicable, just substract one hour from all timestamps used in the MF).
You could for example create two events, on firing at 20.00 and one firing at 19.00. Those two should just check whether they are fired in the applicable DST and continue or break and the issue is solved.
Last but not least, scheduled events are defined as starting point + interval. The meaning of Day is 24 hours (ok, and a few seconds strictly speaking ;-)), and not 'but sometimes 25 hours'.
Ticket 8688 is created for this feature request.