Mapping Time Zones

Learn about managing time zone settings in the Akana Administration Console.

Using the Administration Console Configuration Actions

Table of Contents

  1. Introduction
  2. Supported time zones
  3. Time zone offsets
  4. Understanding configuration parameters for time zones
  5. User's time zone
  6. Use case: setting up time zone for Johannesburg, SA
  7. Troubleshooting time zones

Introduction

The time zones configured in your system have a significant effect on the analytic information you can review and download. It’s important to get time zone settings correct if you want to get hourly or daily charts for more than one time zone.

For example, some parts of the world such as India are in a time zone that differs from GMT not just in one-hour increments, but in a half-hour. 6:00am in Los Angeles in 6:30pm in Mumbai. To get accurate rollup metrics for these different time zones, you would need to configure the time zones and keep data for the half-hour increments.

You can manage the time settings in the Akana Administration Console: Configuration > Configuration Categories > com.soa.rollup.configuration.

The example below shows the installation default values.

com.soa.rollup.configuration

Back to top

Supported time zones

By default, the platform can support all time zones defined in the tz database, also called the IANA Time Zone Database. These time zones follow a basic continent/area format; for example, America/Los_Angeles, Europe/Paris, or Pacific/Fiji. The standard also includes a category, Etc, to support the GMT offset format; GMT+6, GMT-4, and so forth. For example, Etc/GMT-5 represents US Eastern Standard Time. For more information, refer to the Wikipedia article on the tz database.

Although this standard identifies a very large number of time zones, each installation of the Akana API Platform can be configured based on requirements, resources, and efficiency, and might therefore support only a subset. For example, a specific installation might have users in only one time zone, and might therefore be configured to support only that one time zone, which would increase efficiency.

Back to top

Time zone offsets

Most time zones are offset from Coordinated Universal Time (UTC) by some increment of whole hours. For example, when it's 9am in Los Angeles it's 12 noon in New York, 5pm in London, 6pm in Paris, and 2am the following morning in Tokyo.

However, there are some time zones that vary by smaller increments—a half-hour and even in some cases a quarter-hour. The time in Bangalore, India is UTC+5:30 hours. The time in Eucla, in Western Australia, is UTC+8:45.

Back to top

Understanding configuration parameters for time zones

For any standard installation, the scheduled jobs are enabled on one of the Policy Manager instances installed. This is where the events are carried out that upload and delete the rollup data.

In order to get accurate metric rollup results, the configuration parameters that determine the time zone for the rollup data must be correctly specified in the Akana Administration Console for this Policy Manager instance.

To review or modify the time zone settings:

  • From the Akana Administration Console for your Policy Manager instance, go to: Configuration > Configuration Categories > com.soa.rollup.configuration.

Once this is set up correctly for your time zone, the records in MO_ROLLUP_DAY table will get updated on the next 0:00 hrs of the time zone set up. Only after that point will you be able to see the historical charts for the intervals that are dependent on that table: Monthly by Week, Monthly by Day, and Weekly by Day.

This is applicable for both Organization/Tenant level and API level.

You can set up different time zone values as CSV. The scheduled job will write data into MO_ROLLUP_DAY table at every 0:00 hrs of the time zone declared. In this scenario, the table will have multiple records per time zone. For an example, see Use case #1: Results below.

Back to top

User's time zone

Policy Manager also includes a setting in the user profile where the user can set his/her time zone.

To get the expected results when viewing rollup data, it's best to set up the time zone in the user profile to the same setting that you'll want Policy Manager to use for incrementing and displaying the metric data.

To set the user time zone: In Policy Manager, at top right, My Profile > Modify User Profile. An example is shown below.

Time zone example #1: settings

Back to top

Timing of scheduled jobs for rollup data

The table below shows the timing for the scheduled jobs that create the metric rollup information.

This setting... Gets updated...
MO_ROLLUP_DAY When the date hits 0:00 hrs of the time zone, the value reflects in INTVLSTARTDTS
MO_ROLLUPDATA Constantly as the transactions are processed
MO_ROLLUP15 Every 15 min
MO_ROLLUP_HOUR Every hour
MO_ROLL_ORG15 Every 15 min (this reflects Historical charts interval at Org/Tenant level)
MO_ROLL_ORG_H Every hour (this also reflects historical charts interval at Org/Tenant level)

Back to top

Use case: setting up time zone for Johannesburg, SA

Let's say a user wants to configure time zones in such a way that the logs are displayed in Africa/Johannesburg time, and the rollup data is written to the same time zone, so that the historical charts and rollup data are in synch.

Use case #1: Setup

To set this up, the user would need to:

  1. Set up the time zone in the user profile to the correct setting. See User's time zone above.
  2. In the Akana Administration Console for the Policy Manager instance that runs the scheduled jobs, set up the configuration properties as shown below (com.soa.rollup.configuration setting).

    Time zone example #1: settings

Use case #1: Results

The results in the MO_ROLLUP_DAY database table are shown below, with multiple records of the day per time zone.

Time zone example #3: settings

The resulting Historical Charts are shown below: Monthly by Week, Monthly by Day, Weekly by Day, and Weekly by Hour. Information is only displayed for periods that are complete. For example, the Weekly by Day chart only shows completed days, not the current partial day.

Time zone example #4: settings

Back to top

Troubleshooting time zones

In some cases, when time zones were not set up correctly, historical chart information did not display correctly for an API/Tenant (organization), especially with one of these intervals:

  • Monthly by week
  • Monthly by day
  • Weekly by day

In this scenario, the following steps resolved the issue:

  • Make sure that Adobe Flash is enabled in the browser settings.
  • Make sure that the applicable API had transactions invoked for the day or days before the increment date selected.
  • Ensure that the user's profile has the time zone set to the locale reflecting the time zone they are using / have configured in the rollup configuration.

Back to top