Retrieve is different when triggered from scheduled event

3
I have a very simple microflow which is retrieving all orders who are shipped today. I need to export these orders so I built a scheduled event which is triggering this microflow. Problem is that when I trigger the microflow with a microflow button, it works well. I will get a list with orders with shipping date is today. When the scheduled event triggers the microflow, my retrieve returns empty. I'm absolutely sure that my scheduled event and button are triggering the same microflow. I'm trying to retrieve all orders with a shipping date => beginday and shippingdate < endday. Beginday is a variable [%BeginOfCurrentDay%] and endday is addDays($beginDay,1). So I just want to retrieve all orders which are shipped today. Why is the scheduled event causing these issues. Is it something with UTC? It's very strange that something stupid easy like this doesn't work. Some way to work around this? Edit after debug: I placed a breakpoint in the microflow and triggered the scheduled event. My beginday variable has this value: 'Thu Jul 05 02:00:00 CEST 2012'. And my order has a shipdate with 05-07-2012 00:00:00. Edited after answer of David: I've tried to set the default timezone to GMT+01:00(Amsterdam). Then i've added to variables in my microflow. One with [%BeginOfCurrentDayUTC%] and the other one with [%BeginOfCurrentDay%]. Both have the same result: 'Thu Jul 05 02:00:00 CEST 2012'. In other words, the scheduled events are always UTC based.
asked
3 answers
1

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.

answered
0

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.

answered
0

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.

answered