[Resolved] Incorrect Time Zone Used
With the recently added Login Security and Monitoring option, the login time given in the Dashboard is incorrect. Both my server time and WordPress time are set to UTC + 10 hours (correct for my time zone), but the login times are given in the BulletProof log as 10 hours later than actual, i.e. UTC + 20 hours. It seems as if the time offset is being added twice. Could you please look into this?
Many thanks in advance.
Set time to UTC + 10 in WordPress General settings and time was displayed and logged correctly.
May 19, 2013 1:09 am
Please check your php.ini file to ensure that the correct date.timezone directive setting has been used.
It is also possible that another plugin could be affecting this.
Many thanks for your prompt response.
My php.ini does not have an explicit date.timezone directive setting, in my case, this should be
However, my host does not permit me to edit the file. I will ask them to add the directive, but in the meantime is there anything else I can do? Other plugins that I have installed correctly return the right timezone without this directive – presumably they base their date/time solely on the WordPress General setting and/or server time, both of which are correctly set to Australia/Sydney (UTC+10).
hmm that may be what the issue is then.
Email alerts use this function to get the timestamp…
$timestamp = date_i18n(get_option('date_format'), strtotime("11/15-1976")) . ' - ' . date_i18n(get_option('time_format'), $timeNow + $gmt_offset);
…but the variable $login_time uses the php time() function to enter the time into the BPS Login Security Database table. So if your Server time is not set to the correct timezone then I assume that you would see whatever timezone your Server is set too.
$login_time = time();
To test to see if this is the issue do this.
Set your BPS Login Security Logging Options to: Log All Account Logins. Log out of your site and log back in. When you receive the email alert look at the timestamp in that email alert and let me know if it is your correct time.
Thanks for following this up. I did the experiment as you requested.
The log-in time recorded on the BPS Security Login admin page is 20 May 2013 10:34 am. The email alert as received is date/time stamped 20 May 2013 00:34 am (which is correct). There is no date or time contained within the body of the email alert.
Looking at the source/headers of the email, I see these lines:
Subject: BPS Pro Login Security Alert – 20 May 2013 – 12:34 am
Date: Mon, 20 May 2013 00:34:22 +1000
From: WordPress <>
The second line seems to add the extra ten hours.
By the way, before I started this thread, I installed the plug-in “WP Server Date Time” which returns these values:
Server Date/Time: Mon 20th May, 2013 12:49 am
Server Timezone: Australia/Sydney, (EST +10:00)
which is why I believe that my server timezone is set correctly.
(I only activated this plug-in momentarily, though, to check the result it gives because it interferes with something else and mucks up my dashboard view – the plug-in is now deactivated again.)
Edit – actually, looking again at the plug-in’s output I can see that it says EST + 10:00 which is actually incorrect and explains what I’m seeing – I think it should read UTC + 10:00 so there may be an incorrect configuration on my server after all.
This variable –
$login_time = time();Returns the current Unix timestamp for your Server. For the option log all user account logins we did not add addtional email body timestamps for login time or lockout time since the subject line already contains this. For lockouts both the login time and lockout time are relevant and important data.
So it looks like we just need to change the timestamp for the DB entry into the Login Security Database Table. This will be added in the next BPS version release. Thanks for pointing this out.
Many thanks for following this up and I’ll look forward to the fix 🙂
Actually the timestamp code is already working correctly and does not need to be changed so something on your site must be interfering with this. I forgot that the Unix timestamp is converted on the Login Security page by using the same function that generates the timestamp in emails. Since the email timestamp is working then something (another plugin, theme) is causing the timestamp function on the Login Security page not to work/return the correct timestamp.
I set WordPress time to UTC + 10 and all timestamps were changed correctly.
If you have any other plugins that do anything with Logins or something similar then try deactivating those plugins and check the timestamp on the Login Security page. Keep on deactivating plugins until you find the one that is causing this issue and let me know the name of the plugin thanks.
Thanks for the update. I’ll have another look at it as soon as possible but it might take me a couple of days to get back to you.
Yep, no problem. Are you using any other plugins that do something with handling Logins? If so, please list those plugins and I’ll install and test them. Thanks.
My site is not membership based so I just use the WordPress login system. I do have Better WP Security also activated to protect (amongst other things) against brute-force login attempts – I have recently switched this functionality to BPS because all of a sudden BWPS started corrupting my htaccess file (which took my site down each time).
Just to confirm that BPS is working as expected, I installed the “Simple Login Log” plugin – this logs all login attempts, whether successful or not. Overnight, I found there had been 160 login attempts from a single IP (now separately banned), using the same username, over 9-1/2 hours. However, no lockouts occurred (and I therefore received no emails to alert me of this large number of attempts). Does BPS only lockout accounts which exist? BWPS locked out all multiple failed login attempts, which is my preferred response.
Yes, BPS only locks out actual valid user accounts since an invalid user account does not exist in your Database so it could not be locked out unless you did this by IP address, which would be silly because IP addresses can easily be changed/faked so what you would end up with is a huge drain on your Server and database clutter for a pointless reason. If a user account does not actually really exist then it would be impossible to log in with that invalid user account.
Ok I think what is probably happening is that you are using 2 or more Login/Login Security plugin features that are doing the same/similar things and they are conflicting. You cannot have several plugin features doing the same/similar thing. If you have a preferred login security feature in another plugin then use that plugin’s Login features and turn off BPS Login Security.
And just for example sake let’s say I was a hacker and I wanted to crash your website since I found that your login feature was automated to block IP addresses. I could easily do this by overloading your Server if you are blocking by IP address. This would classified as a DoS or DDos Attack.
Example: Use a common automated attack/hacker script that changes IP addresses at an unlimited rate with 1,000’s of IP addresses available in an IP address pool. Use random usernames and constantly switching IP addresses until your website/Server would be overloaded and continue to not load/crash all day long.
We looked into blocking by IP address and discovered with Live testing that it would be very simple and easy to take down websites if they were blocking by IP address. Even using a threshold can be easily beaten since the IP address switch would be automated.
Here is a perfect example of why you do not attempt to handle invalid logins = will crash your website because this is technically a DoS / DDoS vulnerability/exploit that doing something dumb like that causes.
- The topic ‘[Resolved] Incorrect Time Zone Used’ is closed to new replies.