Samet - I assume you have looked at the documentation here
This tells us about new tokens, such as [%BeginOfCurrentDayUTC%] as opposed to [%BeginOfCurrentDay%]. This implies that [%BeginOfCurrentDay%] does not use UTC, but will use the user's timezone. It is not specifically stated what happens when there is no user, such as for a scheduled event, but there is a new setting in the Project settings to set the default timezone for the project...
Have you tried setting this value? You would hope that schedule events would use this default timezone in the same way it is used for anonymous users... but I have not tested.
Edit after Samet's testing: As your testing shows that the scheduled event always runs at [%BeginOfCurrentDayUTC%], I would file a feature request so that scheduled events run in the default project timezone.
In the meantime, you can change your microflow to hard-code an offset from [%BeginOfCurrentDayUTC%] so that it works the same for a user and for a scheduled event, like
addHours([%BeginOfCurrentDayUTC%], 2)Unfortunately you will need a different offset depending on whether daylight savings are in effect or not.
Edit after tests: I did some testing:
1) Date/time tokens interpreted by scheduled actions are always in UTC and ignore both the server timezone and project timezone
2) Client display of date/times is controlled by the machine regional settings, but date/time tokens in microflows are controlled by the timezone set in the user record
3) Samet, addHours([%BeginOfCurrentDayUTC%], 2) worked for me (remember, the dates are actually now always stored on the server in UTC). Clearly, this is only useful if all your users are in the same timezone.
Did you use a breakpoint to see what the difference is when the microflow is triggered manually and when the microflow is started with the scheduled event? Because I think you are in the right direction that UTC must be the difference.
I really think that the Scheduled events should get an overhaul. Indeed there should be an option for setting the time zone of the scheduled event. And also there should be an Boolean checkbox for DST correction on scheduled events (already filled a feature request for this more than a year ago.)
I found yet another example for doing so. I have a scheduled event set on 1-8-2011 at 0600 hours local server time. The repeat interval is set on 1 month. Now can anybody make a guess when this scheduled events runs in July 2012? I bet you do not know the answer.
It runs at 0600 hours on the 7th of July.