While horde and many of the other webmail clients allow users to set their timezone on cPanel servers, it’s also possible to set the default timezone server wide on a cPanel server. You can customize all of the php.ini files in many different ways, but we’re going to focus on the timezone here.

The each of the third party software included in cPanel have their own php.ini that are all build off of one master one here:


Note: this is always a symlink to the real file.

To make changes to the services php.ini files, you want to make your changes there and then run this command:


That distributes the new php.ini file to all 3rd party services.

The gotcha.

At the time of update, if ther are any changes made by cPanel to the 3rd party php.ini file, it will happily overwrite your changes and distribute its new php.ini file to your services, reverting any changes you’ve previously made. To get around this you want to use the postupcp script here:


You have two options from here. If you have a single change you want to make (say the date.timezone), it is much easier and quicker just to add that setting. cPanel won’t set the date.timezone by default, so you can easily just add something like this to your postupcp and it will be all set:

grep -q '^date.timezone' /usr/local/cpanel/3rdparty/etc/php.ini|| echo 'date.timezone=Australia/Brisbane' >> /usr/local/cpanel/3rdparty/etc/php.ini

However, if your php.ini is heavily customized you may want to just replace the entire file. In that case you would want to do something closer to this:

Make your changes to the base php.ini at /usr/local/cpanel/3rdparty/etc/php.ini, and then copy that file somewhere else. For the sake of this example, the file will now reside in /root/custom3rdPartyini/. Now your postupcp script should look something like this:

cp -a /root/custom3rdPartyini/php.ini /usr/local/cpanel/3rdparty/etc/php.ini

To test, and troubleshoot

The easiest way to test whether or not this makes your custom php.ini stick is to run a cPanel update. From the command line run this script:

/scripts/upcp --force

Then use something like this to ensure your changes stuck:

grep date.timezone /usr/local/cpanel/3rdparty/etc/php.ini
grep date.timezone /usr/local/cpanel/3rdparty/etc/horde/php.ini
grep date.timezone /usr/local/cpanel/3rdparty/etc/roundcube/php.ini

If your changes were reverted check these two things:

1) Does your /scripts/postupcp script have the execute bit on it?

If your permissions look like this, you’re going to have a problem:

[~]# ls -lah /scripts/postupcp
-rw-r--r-- 1 root root 0 Mar 13 17:18 /scripts/postupcp

Correct that problem with this command, and check your work:

[~]# chmod +x /scripts/postupcp
[~]# ls -lah /scripts/postupcp
-rwxr-xr-x 1 root root 0 Mar 13 17:18 /scripts/postupcp*

2) Does your script execute properly on the command line?

You should be able to run your script on the command line without error. If you run it, and it throws an error, then address whatever error it gives you and you should be all set!

Happy hooking!