Bizagi allows the use of different timezones in every project. All dates and times are automatically translated from one timezone to another as long as each user has their individual timezone correctly configured for their workplace location. This way worldwide work is possible without losing precision nor saving/considering different dates and times.
If your project requires multiple users to be in different time zones, it is necessary to configure the Server's timezone in the Business Configuration. This is the timezone that Bizagi will use to store all dates in the database (application data, configuration data, log data, scheduler data, user data). If this option is not defined, dates shown in the work portal might be inconsistent.
Keep in mind that all users have their timezone as a user preference.
When a user enters a date or a date-time the Bizagi server converts such date to its server's timezone and always saves it that timezone (not in the timezone that it was entered). However, Bizagi will always present dates considering each user's timezone, so the user who entered the date will always see it just as it was set.
Hence, when a second user in another timezone requests the data, Bizagi converts the date and displays it according to this second user's timezone. This behavior ensures the integrity of the data related to dates and times.
oIf a user does not have a timezone defined, Bizagi will assume he/she is using the project's timezone. So all dates will be displayed to this user, using the project's timezone.
oIf a user HAS a timezone defined, and it is different form the project's one, then Bizagi will DISPLAY ALL dates for this user matching his/her timezone. But all dates will be stored in the project's time zone
oIf a user travels, changing timezone, Bizagi will still consider the timezone defined in his/her preferences. It will only change if the Preferences are updated. The update will affect every single date the users sees.
oUsers should know that Bizagi converts the dates to match their individual timezone to avoid problems when entering dates.
As an example, consider a user called John located in Vancouver (Canada) entering a rendezvous date for his peer Julia in Frankfurt (Germany). The server is located in New Delhi:
•The meeting is for the 12/23/2016 at 19:00 (local time in Germany). Since the dates and times must be registered as local time, John must convert the meeting date to his local time so Julia can see the real date for her. He introduces the following meeting time: 12/23/2016 at 10:00
•The server transforms and saves the date introduced as 12/23/2016 at 23:30 (India time)
•When Julia looks for the meeting time, the server automatically shows it transformed to her timezone (Frankfurt), showing the meeting for the 12/23/16 at 19:00