How Bizagi calculates case and task due dates considering timezones
When you have users using different timezones, based on the hierarchy, for example, users considering the organization timezone, others using the location timezone, and others with an individual timezone. Bizagi has to calculate case and task due dates. This section explains how it is done.
For example, your organization is based in Bogota which is located in GTM -5 time zone (recall that the organization time zone is not the same as the cloud server time zone), and a user of your organization is located in Sydney, which is located in the GTM +10 timezone. Continuing with the previous example, a case is created on Monday at 10 GTM -5, considering the organization's time zone. The user assigned to the task is located in Sydney.
Bizagi uses logic for the calculation of the case due date, different than the activity due date. For the case due date, Bizagi leaves the same hour of the case creation, based on the organization's time zone. Therefore, as seen by the user in Sydney, the case creation is Tuesday 1 am. On the other hand, to calculate the task due date, Bizagi shifts the task creation, so it coincides with the assigned user's timezone.
Date-Time attributes shifted by Time Zones in the Work Portal
Users access the Work Portal, therefore Bizagi can always know the time zone of a user, based on the time zone hierarchy. Based on each user's timezone, Bizagi can calculate the difference between the server's and the user's timezone, and display all date-time attributes on the time zone of the user. For example, consider a project with the following configuration:
•Server time zone GMT +0
•Admon user GMT + 0 (same as server)
•User 1 time zone GMT - 5
•User 2 time zone GMT + 10
User 1 creates a case of a case of a process. Bizagi stores the date-time of the case creation based on the server time and sets this time as GMT + 0. Other users seen in the Work Portal the case creation date have the date shifted based on their respective time zones.
The following date-time attributes are shifted by user's time zone:
•Dates displayed in the Inbox, for example Case creation date, Activity due date or Case due date.
•Dates displayed in query forms
•Date-time attributes displayed in forms.
Date time attributes NOT shifted by Time Zones
In Bizagi, there are multiple attributes that are not necessarily seen by end-users, hence there they do not need to be shifted by the time zone. For example, LDAP synchronization is a programmed task that no end-user executes. Therefore, considers the time zone of the server.
Because in Bizagi Automation Service, the server time zone is UTC +0, this synchronization hour considers the UTC time. Other elements that are not shifted are listed:
•Traces displayed in the Management Console Web
•DateTime.Now expression in business rules.
•DateTime attributes used within web services or connectors (used in mappings).
Using .NET framework date time functions
When you use functions that are part of the .NET framework like the DateTime.Now or DateTime.Today function, recall that this function is not shifted by any time zone, therefore, and it returns the UTC date and hour.
The DateTime is a .NET function that belongs to the System namespace. Therefore, when you use methods that belong to the System namespace, are executed at the server side, meaning that are executed in the Bizagi web app. As mentioned in How to manage your Time Zones, the standard time in Automation Service is UTC. Any time you use date-time functions from the System namespace, they are going to be based on the UTC.
If you need to return the date shifted by a time zone, you need to add the hour difference with the time zone.
Additionally, the culture of .NET framework native methods is based on en-us (United States English). Therefore, the format of date-time functions is based on en-US.
The following list of functions are based on UTC and en-US culture:
For further information see the DateTime Struct.
For further information see the TimeSpan Struct.