This proves that the problem is what Davide told you all along: your server has the wrong time set on it.
Please note that there are
THREE different things that your host must check:
1.
The timezone of the server. Typically stored in /etc/localtime or /etc/timezone it must match the location of the server.
2.
The timezone in php.ini. It has to match the timezone above. In case you are overriding php.ini values in local php.ini files inside your site; or any .htaccess file into any path leading from the root of the filesystem to where the script is located; or any .user.ini files into any path leading from the root of the filesystem to where the script is located: you must make sure you are NOT overriding the system's timezone.
3. The date and time itself.
I would like to stress that setting the time itself is NOT enough. For example, at the time of this writing it's 16:17 EEST which translates to 13:17 UTC. If I was stupid enough to set my timezone to GMT (even though my computer is in Athens, Greece therefore in EEST timezone which is GMT+3 due to Daylight Savings Time) and set my clock to 16:17 then
echo date('Y-m-d H:i:s'); would look MISLEADINGLY correct. I believe this is what your host did. If I, however, did the CORRECT date dump, i.e.
echo date('Y-m-d H:i:s T'); which prints the timezone or, even better,
echo gmdate('Y-m-d H:i:s'); which returns the GMT time I would have noticed the fact that my runtime clock is set
three hours into the future.
Furthermore I'd like to stress that running ntpd / ntpdate (depending on the age of the Linux distribution) manually
is not enough. In fact, if the time of the server deviates to the time of the atomic clock it connects to by more than 1000 seconds (16 minutes 40 seconds) ntpd will NOT update the local time, NOT throw an error and only set an error code. I've hit that issue twice, once setting up my Raspberry Pi (no hardware real time clock on this puppy!) and once setting up my CCTV system. In both cases I had to set the time manually to a good approximation, i.e. within a few seconds of the actual time, then run ntpd.
Please note that I've hit the exact save issue you are experiencing twice on our site last year when SiteGround had inadvertently turned off the NTP daemon. Every three weeks the clock would deviate more than 15' and my backups would fail uploading. The second time I asked to speak to an engineer, told him that the NTP daemon is probably not running and he fixed it. No problems ever since. I have twice daily backups delivered to S3 without fail
every single day the last 11 months. So, no bug here. I have our site's backups to prove it ;)
Also, the date and time for the signature is fetched using this very simple code:
echo gmdate('D, d M Y H:i:s T'); (I added the echo for your benefit. The actual code is a variable assignment but the important thing is the gmdate call). You can check its output against www.timeanddate.com/worldclock/timezone/utc If the two outputs differ for more than 15' (I can guarantee they do) you know that you have to ask your host to fix the issue without any more excuses.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
