Mapping Time Zones
Learn about managing time zone settings in the Akana Administration Console.
Table of Contents
- Supported time zones
- Time zone offsets
- Understanding configuration parameters for time zones
- User's time zone
- Use case: setting up time zone for Johannesburg, SA
- Troubleshooting time zones
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.
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.
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.
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.
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.
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_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)|
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:
- Set up the time zone in the user profile to the correct setting. See User's time zone above.
- 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).
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.
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.
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.