How to upgrade timezonedb/timelib on php7 (plesk onyx)?
Context
I've solved a similar problem in my company, but related to daylight saving time in Brazil. The time was 1 hour wrong in all our servers that uses PHP 7.0.32, while the servers that uses PHP 7.1 are working fine.
Our servers are running on AWS EC2 instances. Our timezone is America/Sao_Paulo. It's important to note that our main goal was "update timelib PHP extension", but we found that was not needed, since updating the timezone database version was enough to solve our problem.
Solution
In order to solve that outdated datetime, I've run the following commands from SSH, logged in as root user:
pecl7 install timezonedb
After that, we need to add the extension to our PHP.INI file. In my case it was loaded and located from /etc/php.ini. To check yours, just create a phpinfo.php file and check from which location your machine is loading the php.ini file:
Then, just run somewhat like:
nano /etc/php.ini
And then add the following line to the last line of your php.ini file:
extension=timezonedb.so
In order to check if the update has made sucessfully, restart php / php-fpm with the following command:
service php-fpm restart
Then, let's access again the PHPINFO and...
After updating the system tzdata package, will PHP use this new data?
According to the notes from the timezone_version_get function, 0.system means that you are using the version that PHP shipped with. It does not mean that you are using the tzdata from your operating system.
On each release of PHP, the most current timezonedb package data is incorporated into the PHP distribution. However, a new release of the time zone database doesn't necessarily force a release of PHP. Therefore, if you want the most current version of the time zone data, then your only option is to update the timezonedb package yourself.
Incomplete list of timezones generated by PHP
Your timezone database might not be up-to-date.
Try following the link at the bottom of the List of Supported Timezones page :
The latest version of the timezone
database can be installed via PECL's »
timezonedb.
Edit after the comments : to update your timezone database, as you are on a Linux system, you can use the pecl command (I just tried this on my Ubuntu machine) :
pecl upgrade timezonedb
This will download the new version, and compile it.
Then, if you enable the new timezonedb extension, your PHP should use an uptodate database :
php -dextension=timezonedb.so -i | grep Timezone
"Olson" Timezone Database Version => 2011.5
Timezone Database => external
Alternative Timezone Database => enabled
Timezone Database Version => 2011.5
If I try without enabling that new extension, I get the same kind of thing you had before :
php -i | grep Timezone
"Olson" Timezone Database Version => 0.system
Timezone Database => internal
PHP Timezone List
Take my array of time zones, which I made specially for select element. It is associated array where key is PHP time zone and value is human representation. This is it:
$timezones = array(
'Pacific/Midway' => "(GMT-11:00) Midway Island",
'US/Samoa' => "(GMT-11:00) Samoa",
'US/Hawaii' => "(GMT-10:00) Hawaii",
'US/Alaska' => "(GMT-09:00) Alaska",
'US/Pacific' => "(GMT-08:00) Pacific Time (US & Canada)",
'America/Tijuana' => "(GMT-08:00) Tijuana",
'US/Arizona' => "(GMT-07:00) Arizona",
'US/Mountain' => "(GMT-07:00) Mountain Time (US & Canada)",
'America/Chihuahua' => "(GMT-07:00) Chihuahua",
'America/Mazatlan' => "(GMT-07:00) Mazatlan",
'America/Mexico_City' => "(GMT-06:00) Mexico City",
'America/Monterrey' => "(GMT-06:00) Monterrey",
'Canada/Saskatchewan' => "(GMT-06:00) Saskatchewan",
'US/Central' => "(GMT-06:00) Central Time (US & Canada)",
'US/Eastern' => "(GMT-05:00) Eastern Time (US & Canada)",
'US/East-Indiana' => "(GMT-05:00) Indiana (East)",
'America/Bogota' => "(GMT-05:00) Bogota",
'America/Lima' => "(GMT-05:00) Lima",
'America/Caracas' => "(GMT-04:30) Caracas",
'Canada/Atlantic' => "(GMT-04:00) Atlantic Time (Canada)",
'America/La_Paz' => "(GMT-04:00) La Paz",
'America/Santiago' => "(GMT-04:00) Santiago",
'Canada/Newfoundland' => "(GMT-03:30) Newfoundland",
'America/Buenos_Aires' => "(GMT-03:00) Buenos Aires",
'Greenland' => "(GMT-03:00) Greenland",
'Atlantic/Stanley' => "(GMT-02:00) Stanley",
'Atlantic/Azores' => "(GMT-01:00) Azores",
'Atlantic/Cape_Verde' => "(GMT-01:00) Cape Verde Is.",
'Africa/Casablanca' => "(GMT) Casablanca",
'Europe/Dublin' => "(GMT) Dublin",
'Europe/Lisbon' => "(GMT) Lisbon",
'Europe/London' => "(GMT) London",
'Africa/Monrovia' => "(GMT) Monrovia",
'Europe/Amsterdam' => "(GMT+01:00) Amsterdam",
'Europe/Belgrade' => "(GMT+01:00) Belgrade",
'Europe/Berlin' => "(GMT+01:00) Berlin",
'Europe/Bratislava' => "(GMT+01:00) Bratislava",
'Europe/Brussels' => "(GMT+01:00) Brussels",
'Europe/Budapest' => "(GMT+01:00) Budapest",
'Europe/Copenhagen' => "(GMT+01:00) Copenhagen",
'Europe/Ljubljana' => "(GMT+01:00) Ljubljana",
'Europe/Madrid' => "(GMT+01:00) Madrid",
'Europe/Paris' => "(GMT+01:00) Paris",
'Europe/Prague' => "(GMT+01:00) Prague",
'Europe/Rome' => "(GMT+01:00) Rome",
'Europe/Sarajevo' => "(GMT+01:00) Sarajevo",
'Europe/Skopje' => "(GMT+01:00) Skopje",
'Europe/Stockholm' => "(GMT+01:00) Stockholm",
'Europe/Vienna' => "(GMT+01:00) Vienna",
'Europe/Warsaw' => "(GMT+01:00) Warsaw",
'Europe/Zagreb' => "(GMT+01:00) Zagreb",
'Europe/Athens' => "(GMT+02:00) Athens",
'Europe/Bucharest' => "(GMT+02:00) Bucharest",
'Africa/Cairo' => "(GMT+02:00) Cairo",
'Africa/Harare' => "(GMT+02:00) Harare",
'Europe/Helsinki' => "(GMT+02:00) Helsinki",
'Europe/Istanbul' => "(GMT+02:00) Istanbul",
'Asia/Jerusalem' => "(GMT+02:00) Jerusalem",
'Europe/Kiev' => "(GMT+02:00) Kyiv",
'Europe/Minsk' => "(GMT+02:00) Minsk",
'Europe/Riga' => "(GMT+02:00) Riga",
'Europe/Sofia' => "(GMT+02:00) Sofia",
'Europe/Tallinn' => "(GMT+02:00) Tallinn",
'Europe/Vilnius' => "(GMT+02:00) Vilnius",
'Asia/Baghdad' => "(GMT+03:00) Baghdad",
'Asia/Kuwait' => "(GMT+03:00) Kuwait",
'Africa/Nairobi' => "(GMT+03:00) Nairobi",
'Asia/Riyadh' => "(GMT+03:00) Riyadh",
'Europe/Moscow' => "(GMT+03:00) Moscow",
'Asia/Tehran' => "(GMT+03:30) Tehran",
'Asia/Baku' => "(GMT+04:00) Baku",
'Europe/Volgograd' => "(GMT+04:00) Volgograd",
'Asia/Muscat' => "(GMT+04:00) Muscat",
'Asia/Tbilisi' => "(GMT+04:00) Tbilisi",
'Asia/Yerevan' => "(GMT+04:00) Yerevan",
'Asia/Kabul' => "(GMT+04:30) Kabul",
'Asia/Karachi' => "(GMT+05:00) Karachi",
'Asia/Tashkent' => "(GMT+05:00) Tashkent",
'Asia/Kolkata' => "(GMT+05:30) Kolkata",
'Asia/Kathmandu' => "(GMT+05:45) Kathmandu",
'Asia/Yekaterinburg' => "(GMT+06:00) Ekaterinburg",
'Asia/Almaty' => "(GMT+06:00) Almaty",
'Asia/Dhaka' => "(GMT+06:00) Dhaka",
'Asia/Novosibirsk' => "(GMT+07:00) Novosibirsk",
'Asia/Bangkok' => "(GMT+07:00) Bangkok",
'Asia/Jakarta' => "(GMT+07:00) Jakarta",
'Asia/Krasnoyarsk' => "(GMT+08:00) Krasnoyarsk",
'Asia/Chongqing' => "(GMT+08:00) Chongqing",
'Asia/Hong_Kong' => "(GMT+08:00) Hong Kong",
'Asia/Kuala_Lumpur' => "(GMT+08:00) Kuala Lumpur",
'Australia/Perth' => "(GMT+08:00) Perth",
'Asia/Singapore' => "(GMT+08:00) Singapore",
'Asia/Taipei' => "(GMT+08:00) Taipei",
'Asia/Ulaanbaatar' => "(GMT+08:00) Ulaan Bataar",
'Asia/Urumqi' => "(GMT+08:00) Urumqi",
'Asia/Irkutsk' => "(GMT+09:00) Irkutsk",
'Asia/Seoul' => "(GMT+09:00) Seoul",
'Asia/Tokyo' => "(GMT+09:00) Tokyo",
'Australia/Adelaide' => "(GMT+09:30) Adelaide",
'Australia/Darwin' => "(GMT+09:30) Darwin",
'Asia/Yakutsk' => "(GMT+10:00) Yakutsk",
'Australia/Brisbane' => "(GMT+10:00) Brisbane",
'Australia/Canberra' => "(GMT+10:00) Canberra",
'Pacific/Guam' => "(GMT+10:00) Guam",
'Australia/Hobart' => "(GMT+10:00) Hobart",
'Australia/Melbourne' => "(GMT+10:00) Melbourne",
'Pacific/Port_Moresby' => "(GMT+10:00) Port Moresby",
'Australia/Sydney' => "(GMT+10:00) Sydney",
'Asia/Vladivostok' => "(GMT+11:00) Vladivostok",
'Asia/Magadan' => "(GMT+12:00) Magadan",
'Pacific/Auckland' => "(GMT+12:00) Auckland",
'Pacific/Fiji' => "(GMT+12:00) Fiji",
);
Storing specific Date/Time values for users in different time zones
Since you are talking about scheduling of future time, storing only UTC isn't necessarily the best approach.
Keep in mind that time zone rules can (and do) change. If you apply an update to your time zone data (in PHP, it's done with PECL's timezonedb package), then any data you already converted to UTC might be invalid.
The better solution is to store multiple values:
The original local date and time
The original time zone (ex.
"America/New_York")The UTC date and time, converted from the local values
When you want to see if it's time to run the task, you'd compare the current UTC date and time against the stored UTC value.
When you apply time zone updates, you throw out the previous converted UTC values for all future entries, and recalculate new ones based on the updated data.
If you don't do this, then you're losing the intent that the user originally provided. And if you don't keep your time zone data updated, then your system won't be aware of various changes happening around the world, such as the changes made in Egypt earlier this year, or the changes coming in October for Russia.
Last point - If implemented properly, the time zone of your server should not matter. Compare UTC to UTC.
Related Topics
Pdoexception' with Message 'Sqlstate[22001]: String Data, Right Truncated: 0
How to Get the Current PHP Executable from Within a Script
Phpstorm 2020.2 - PHP Built-In Functions Are Not Recognized
How to Make First Letter of a Word Capital
Passing Variable from Controller to View in Codeigniter
PHP Fatal Error: Call to Undefined Function Mssql_Query()
Warning: MySQLi_Query() Expects at Least 2 Parameters, 1 Given. What
PHP for ; Foreach Variable Scope
How to Install PHP_Id3 on Wamp
Php: How to Convert Bigint from Int to String
Mongodb Get _Id as String in Find Query
How to Select MySQL Query with Foreign Language
Codeigniter PHP Stylesheet Link. How
Read and Write to a File While Keeping Lock
I Want a Pagination to My Options Page of Wordpress Plugin
HTML Purifier: Removing an Element Conditionally Based on Its Attributes