The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Server Ideas

Share your Server product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

Make Scheduler Time Zone Aware

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. 



Problem 1:

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. 


Problem 2:

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. 





6 - Meteoroid
I agree that that showing the time zone on the "Schedule" view is needed. I also notice that the "Results" view that shows when the workflow actually ran shows the result in my local time zone. So the "Schedule" view and the "Results" view are not showing the same time when the server is located in a different time zone. These two views should be coordinated. At the very least show the time with the time zone on each view.
Alteryx Alumni (Retired)
Status changed to: Accepted

@rdoptis@BARTONCONNIE, and @RonL - thank you for all of your thoughts on this.  I'm marking this post as "On the Roadmap" as we are looking at making Scheduling enhancements in the Gallery during the course of 2018 and gracefully handling time zones is on the list.  Thanks again for all of your input!

Alteryx Alumni (Retired)
Status changed to: Duplicate

Hi all, I am marking this post as a duplicate to an original post, @rdoptis references from 2015, that can be found: We have updated that idea being "on the roadmap".  Thank you again for all of your input!

Alteryx Alumni (Retired)
Status changed to: Duplicate

Thanks again for this post, @gnans19.  We've had a handful of separate idea posts on this very topic so I am marking this as a duplicate and linking everyone to an original post that can be found here: We updated the idea as being on the roadmap and will be sure to keep that post up-to-date as we make progress.  Thank you very much for your input! 

17 - Castor
17 - Castor

Working with @BenBu we discovered that the time stamped on jobs in the logs on the server may be in different timezones depending on the worker's timezone.


This leads to odd behaviors where a job may appear to end before it starts because the controller stamps the start time, and the worker stamps the end time.

All times should be logged as UTC, taking into account the worker & controller's timezone - that way this issue will not occur.


cc: @avinashbonu ; @Deeksha ; @revathi

Alteryx Alumni (Retired)
Status changed to: Under Review

Thank you @SeanAdams for the idea. We could see how this simple change to UTC would ensure reading the logs and comparing timestamps is consistent. There are some customers that prefer not to do the addition/subtraction with different timezones. Regardless, we appreciate the idea and will see what we can do to account for the problem as we enhance our logging.

17 - Castor
17 - Castor

Thanks @MattB


Whether or not we use fully loaded UTC - the issue still remains that in large corporate environments where the server and the worker nodes may be in different timezones, we need to be able to understand the actual time that a job took.   So the current structure where the controller stamps the start of the job (in timezone A) and the worker stamps the end of the job (in timezone B) creates unusable data logs.


Whether we solve this by making the controller accountable for all pieces; using UTC; using a new date-time format that is timezone aware ( @Ned@AdamR_AYX ) - these are all possible options, as long as we solve the core problem that a job cannot finish before it starts and that's what the server logs currently tell us because of this timezone issue across workers and controllers.


 cc: @patrick_digan @MarqueeCrew @jdunkerley79 @BenBu @DamianA



8 - Asteroid

Today, which is the first time I ever scheduled a workflow, I hit this problem. My time zone is GMT, but the server I am using is GMT-6hrs. I'm only playing/learning, so no problem. Better I learned about this now than when setting up some business-critical schedule!



8 - Asteroid

This post illustrates the current state of how the Gallery and Scheduler interact with time zones as of V11.7. The behavior it showed in that test is unintuitive and may lead to issues with setting schedules correctly. One possible correction would be to unify all times on the server to server time, but I think we can do better.


What I suggest instead is to add time zone as an option on the scheduler. This way users that set schedules don't ever have to wonder at what time the workflow is actually going to run. That information can also be passed through to results such that users that want to make sure a schedule is working as planned don't have to back track and figure out if 5pm means 5pm their time or server time. Finally, it would allow a more intuitive way for an employee in Denver, CO schedule a workflow such that his or her boss in Irvine, CA receives the resulting report exactly when needed/expected.

12 - Quasar

I agree, it can be very annoying when trying to schedule