Skip to Content

Time zones in Jitterbit App Builder

Overview

App Builder supports showing DateTime fields in the user's local time zone. The Time Zone setting in App Builder for a data source should match the data source's time zone. Usually this is set the same as the time zone of the machine itself. In either case, the time zone set for a data source should match the expected time zone returned when executing a Now() statement on the database.

Caution

The recommendation is that the App Builder application server and database Servers are both configured with the same timezone. These servers need to be in sync. Future versions of App Builder may refuse to run if the clocks between the application server and database server are out of sync.

Configuration

There are two locations that a Time Zone can be configured:

  1. Data Source Server
  2. Data Source

The Time Zone setting uses IANA time zones (e.g., America/New_York).

Data source server

By configuring a Data Source Server Time Zone, all newly created Data Sources on this server will be configured with the same Time Zone. Existing Data Sources are unaffected.

Configuration steps

  • Navigate to IDE > Data Servers
  • Locate your Data Server and click the corresponding Details button
  • Go to More > Edge Case
  • Click Edit
  • Configure the Default Data Source Time Zone
  • Click Save

Data source

By configuring a Time Zone on a Data Source, all DateTime fields will be rendered according to the user's local time zone.

Configuration steps

  • Navigate to IDE > Data Servers
  • Select the appropriate Data Server
  • Locate the appropriate Data Source and click the corresponding Details button
  • Click the Advanced Settings button
  • Click Edit
  • Select the appropriate Time Zone
  • Click Save

Impact

All DateTime fields will be shown in the user's time zone once a time zone has been set on a Data Source. This will affect the following:

  • Table DateTime columns.
  • Business Object DateTime columns.
  • Rule DateTime columns (Bridges, CRUD, Validations, Webhooks, etc).
  • Page controls which are bound to one of the above DateTime columns.
  • Dynamic Results screen for all of the above.

For Business Objects and Rules, the target Data Source Time Zone will be followed.

In addition, Full Audit and Audit Lite DateTime fields will take into consideration the Data Source's Time Zone. This may cause a divergence from historical data. To handle this more seemlessly, see the Date migration feature which will migrate all existing data to the new Time Zone.

Determining the user's time zone

App Builder follows these priority-order steps to determine the user's time zone:

  1. First, check if the user profile has a Time Zone setting. If so, use it.
  2. Otherwise try to get the browser's Time Zone setting.
  3. Lastly, try to get the browser's Time Zone Offset setting.

If none of the above settings are available, the user's Time Zone will default to the App Builder application server's Time Zone.

Important notes

  • Setting a Time Zone does not affect any of the existing data within a Data Source. If DateTime data needs to be adjusted from one time zone to another (e.g. Audit data), the Date migration feature should be used instead.
  • The adjustment of DateTime data to the user's time zone is a purely superficial change. Dates going out to a client are adjusted to the user's Time Zone. Dates sent from a client to the server are adjusted back to the server's Time Zone before any App Builder rules are run.
  • Furthermore, DateTime data CRUD'ed from one Data Source to another will not be adjusted whatsoever. Again this is purely a superficial change which only impacts the DateTime seen by a client.
  • Take care that the Dynamic Results screen will be impacted by the Time Zone setting. This means that a developer may see a different DateTime within the App Builder Results screen than within a direct database viewer like SQL Server Management Studio.