In larger organizations or organizations with global coverage, it is possible for users to be in different time zones from each other and the Alteryx server.
WIth our implementation of Alteryx server, we have the server time zone set to that of our data warehouse, but this time zone is different than my own by -2 hours. In the case of scheduling a workflow in the future, I normally correct for this by setting the scheule in the time zone of the server and things work alright.
It falls apart is when I want to schedule something in the future, but it is within the timespan between my time zone and the server time zone. For example: It is 6PM my time, and 4PM server time. I want to schedule a workflow to run at 5PM server time (7PM my time). When I try to set this up with the Version 10 scheduler built into Alteryx desktop, it overides the date field upon saving to run the following day instead of today as it thinks im trying to schedule the run at a time that has already passed (which it has in my timezone, but not in the server time zone). Upon trying to edit this schedule to reset the date to today, it again reverts upon saving.
The only way I have found to get around this is to reset the time zone of my computer to match the server time zone, then set the schedule, then reset the time zone of my machine back to local time again. This is not the best experience, and will likely be required more frequently for users as their time zone difference increases.
When wanting to run something server side immediately (I do this in cases where the runtime will be long, or im mobile and on a machine with a lower amount of processing resources) the "Once" option can be used in scheduler to push something to server and run it. In my case, due to the timezone difference, the default time set when trying to do this is the current time in my time zone, but 2 hours ahead of the current server time.
I have two proposed resolutions:
1) Transmit Server time zone information to the local scheduler to have everything involving scheduling in Server time. Also for any timestamp fields, include the time zone designation so its clear to the user.
2) Use information from the user's machine and information from the server to do timezone conversions behind the scenes so whenever scheduling or viewing schedules, all timestamps are in local time to the user. I feel this is the prefered solution for the best user experience, but would also be the more complex to implement.