Time Data for Machines -vs- Rendering Time Data for a Person
TeamworkIQ's APIs and Zapier integration treat all time stamps and time data using the UTC timezone typical of best practices for most computer software. However, you might want to render that "universal" time data for a specific timezone for your users.
For example, when it's 0:00:00 UTC, it's 4:00 PM in San Francisco for about half of the year, and due to Daylight Savings Time conventions, its 5:00 PM for the other half of the year. Thus to render a meaningful time to a person working in a certain timezone, you must provide a timezone.
TeamworkIQ does this automatically for users who have set their personal Timezone in their User Profile.
However, there are some cases where, when using the API or Zapier integrations, the underlying code or integration needs a Timezone to its job.
When rendering dates and times in a Process Title or Process Tags generated from a Template.
Consider this Template configuration for a Process Title and Process Tags:
The Template's Process Title setting is configured to render the "process-started-hour" date in a "mmm-d, yyyy" format (e.g. Mar-1, 2020). However, when launching this process from a template, there is no human user whose timezone can be used to figure out what timezone to use. Thus, the Default Timezone for the App Integration will be used.
Similarly, in the example above, the "process-started-hour" variable rendered as its "year" is used to dynamically generate a tag for the "year" that the process is started. Here too, a Timezone is needed to figure out if Dec-31 at midnight UTC is really Jan-1 of the next year for the people who will be using this process. The Default Timezone for the App Integration helps make that determination.
IMPORTANT: The above only applies to processes started via the API or Zapier. If a Member of the Account manually launches a process, then the timezone for that Member is used to render any formatted date variables in the Process Title and Process Tags.