Search Engine: Elastic

Article ID: 131718, created on Nov 3, 2017, last review on Apr 17, 2018

  • Applies to:
  • Business Automation 7.0

Applies to

The issue applies to any OA Billing installation of 7.0.1 and later version that runs on CentOS 7.0/RHEL 7.0 and later.


You may face the time mismatch in Billing PCP:

  • wrong task registration time in Billing task manager (Billing PCP > Operations > Tasks),

  • wrong deliver lines start and end dates (and, probably prices) in AR documents,

  • and alike.

This is explained by the fact that the Billing application uses a wrong time zone for datetime values retrieved and/or saved into the database.

The issue appears in any of the following cases:

  • you migrated your installation to CentOS 7/RHEL 7 and later,

  • you updated your installation's OS components (for example, by running yum update),

  • you manually updated the timezone on your intallation's OS with timedate_ctl.


The libicu library, which is a part of CentOS 7 distribution, is used by Billing application for time zone conversion in different rating algorithms. This library obtains the default time zone information from a system file /etc/localtime on the Billing Application node, which is typically a symlink to a time zone file specific to the server's location (e.g. /usr/share/zoneinfo/Europe/Sofia).

The CentOS 6 -> CentOS 7 Billing migration script generates the symlink in a relative, rather than absolute, path format during migration. Because of that, the libicu library cannot locate the default time zone information file and falls back to a very rough algorithm to guess the server's timezone. This algorithm does not take daylight saving time into account, which results in the mismatch.

In case of manual update of time zone (using the timedate_ctl utility on CentOS 7), the utility uses a relative path to the time zone file, which results in the same problem.

In case of manual update of CentOS 7 by yum update, a path to the time zone file will be reset to relative one, which results in the same problem.


Warning: This should be done in a maintanence window, because restart of the Billing service is required.

In order to resolve the issue, you need to:

  1. Go to your Billing Application node.
  2. Run following command:

    ls -l  /etc/localtime
  3. Observe the output:

    • [root@pbalinfe01 ~]# ls -l  /etc/localtime
      lrwxrwxrwx 1 root root 30 Oct 21 11:27 /etc/localtime -> ../usr/share/zoneinfo/migrated

    Relative path with migrated time zone should be fixed. Follow the steps below.

    • [root@pbalinfe01 ~]# ls -l  /etc/localtime
      lrwxrwxrwx 1 root root 30 Oct 21 11:27  /etc/localtime ->  ../usr/share/zoneinfo/

    Relative path should be fixed. Follow the steps below.

    • [root@pbalinfe01 ~]# ls -l  /etc/localtime
      lrwxrwxrwx 1 root root 30 Oct 21 11:27 /etc/localtime -> /usr/share/zoneinfo/

    Absolute path is correct. However, specify the necessary timezone explicitely in global.conf to prevent the issue in the future. Follow the steps 5-6 below.

  4. Fix the symlink to point to a specific timezone file:

    rm /etc/localtime
    ln -s /usr/share/zoneinfo/<timezone_file> /etc/localtime


    <timezone_file> is the file specific to the actual server's time zone.

  5. Prevent the timezone reset by specifying the necessary timezone explicitly (to prevent the timezone reset in future):

    5.1. Go to /usr/local/bm/etc/ssm.conf.d/.

    5.2. Open global.conf for editing.

    5.3. In the [environment] section, add the following line:



    <your_TZ_in_Olson_format> is the timezone you need (for example, Europe/Sofia, or Australia/Sydney, or Europe/Moscow, or the like).

  6. Restart the billing service:

    # service pba restart

198398b282069eaf2d94a6af87dcb3ff caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07 c0f836394088a28cc30dd0e5fe8b600e b2c3b33425dfc50c7d41a2efaa7f84f3

Email subscription for changes to this article
Save as PDF