In 3.0 the handling of time is definitely improved. But I had hoped that a solution for daylight saving time (DST) was also implemented see also forum discussion: Server time and DST The problem still is that with scheduled events I can either choose between server time and UTC time. But both give me problems when the DST kicks in. When UTC is used the offset changes and when I choose server time the time does not get adjusted because it calculates from the starting date and adds 24 hours to it. So when I choose a date in the summer it is on a different time then when I choose a date in the winter. This may be seems a bit confusing but to clarify when I set the date somewhere in June 2200 hours this event will now (in November when DST is active) run on 2100 because the calculation does not recalculate for DST. The solution to this problem is to add a adjust for DST Boolean in the scheduled event setting. I already filled a feature request that is in the backlog and I hope this feature will be implemented soon. Or am I missing something completely here and can this problem be circumvented in 3.0?
asked
Ronald Catersels
1 answers
2
Simply use UTC time, UTC does not have a daylight savings time so it won't be adjusted. It won't help you if you MUST always run something at for example 4 AM local time though.