Wordfence Reporting Times

Hi Clint,
the warnings sent via email come from automated scans. If you run a manual scan on your website the warnings should pop up there as well, assuming they are still relevant and the problem hasn’t already been fixed. (Occasionally people will get false positives if the scan runs at the exact same time as a plugin is being automatically updated).

Hi Clint!
Thanks for checking back in. Unfortunately I did not. Strangely I have not seen any other reports identical to yours. We use filemtime PHP function to get the modified time so the time reported in activity email definitely should be the same as the server time. When you get an email if you manually go in via FTP/SSH and check the last modified date on the file in question, does it match the time stated in the email?

Hi cwdv,
just following up here on cases that haven’t been resolved. I have been keeping a lookout but have not seen this issue elsewhere nor have I been able to reproduce it. The only logical explanation is that even though your WordPress settings for timezone are correct, some plugin, theme or custom code is modifying the timezone within the WordPress environment. If you search through all the files on the site and look for the string “timezone” for example, you may be able to find it.

The short version.. Linux (your server) has a very different idea of time/timezone from PHP/WordPress. Both must be synchronized, if you want “outside” timestamps (like file modification times ) to show VISUALLY same in WordPress.

The long version:

Apples and Oranges. (Mixed with some Watermelon and a big squirt of Lemon).

Apples: Linux systems internally count “Seconds since the Unix Epoch” (Jan 1 1970) IN UTC. Always UTC.
A simple Integer clicking along. That simple integer is what the php call “filemtime” correctly returns to WordFence, an “ls -l” on the SSH command-line. filemtime() is a simple PHP hook to Linux’ own filesystem call.

Oranges: The date shown in Linux (if you ask or set with the “date” Linux command), or look at file modification times is is done by converting the Unix Epoch counter returned from the kernel and calculating current date/time from there. By how many times we have counted “one second” since 1970. ALWAYS in UTC time. 🙂 The exact date/time SHOWN then further depends on the Server’s TZ (Timezone) settings. Done by simply adding/subtracting from UTC using the Timezone setting. That is what the local hosting admins are talking about when they talk about their system’s timezone.
Most admins think think they are setting a date/time, but in reality when setting time, the system calculates backwards to get a new “Epoch time” from the date/time you give it, That “Epoch time” is then set in the kernel.

The server (the Linux kernel running the system) does not care one-iota about timezones.. It knows seconds (actually microseconds) since Jan 1, 1970 UTC. TZ is a local conceptual thing added on top of it all, used to satisfy us human beings who do not count microseconds that well.. 🙂

A BIG FAT Watermelon: PHP has it’s own idea of what timezone should be assumed. It is typically set in your global php.ini file with the “date.timezone” config, or set with date_default_timezone_set() within a script. Like anywhere in WordPress. That makes PHP totally ignorant of what the Servers notion of timezone is.. PHP does not care.
What PHP and Linux have in common, though, is “seconds since Unix Epoch” or “Epoch time”.
But unless their TZ settings are synched up, they then convert it differently when displaying it to us humans. 🙂 Just to make our lives more interesting. 🙂 PHP asks for the “Epoch” time, just like Linux itself does, and then converts that into PHP’s own notion of what timezone it is in. And the “file modification time” WordFence get’s from Linux is an “Epoch time” time-stamp. 🙂
PHP’s notion of TZ affects the output from all the standard PHP Date and time type functions, which makes it very possible that a PHP date() function can return a date/time string quite different from the Unix system’s date command. Linux and PHP running with different timezone configs, but they BOTH calculate their idea of a date from the “Unix Epoch” returned by the Linux kernel. 🙂

Now for the Lemon part, or the EXTRA fly in the ointment. WordPress.. WordPress by default ignores your Server AND PHP settings for timezone.
It calls “date_default_timezone_set( ‘UTC’ );” directly in the wp-settings file, which makes all WordPress sites all over the world default run in UTC time, unless a site-specific change (a call to date_default_timezone_set) is hit.
JUST LIKE LINUX DEFAULT. 🙂

WordFence as far a I know uses only the a simple PHP date() call to convert each file’s Epoch value into a human readable. That will always make it show a local “PHP time”, dependent on PHP’s timezone idea. That might have been changed by WordPress along the way, but it is totally and completely independent on whatever conversions the Linux system has done based on ITS OWN TZ config. Unrelated to what “modification time” Linux shows when you do an “ls -l” on the command line. Unless configured to run in the same exact timezone, Linux and PHP will each convert “seconds since Unix Epoch” differently. 🙂
And “Epoch time” is what all file modification timestamp are.

WordFence can be affected by both PHP timezone (and by WordPress) because wordpress uses the “date_default_timezone_set()” to set their own idea of Timezone. Default always UTC.

Some plugins, like Yoast SEO, ALSO calls date_default_timezone_set() and will RESET your PHP timezone to UTC directly in PHP if your PHP is NOT configured in PHP.ini. They look for it. 🙂 But when random plugins call date_default_timezone_set() at odd times, they are changing the PHP system. Which affects others, including WordPress. 🙂

Here is the rub.. It normal cases in WordPress, the choice is simple.. You want posts and comments to show “site-time”, as in the time set in your site’s timezone config.

But for plugins like WordFence, where these filelistings really represent a SYSTEM or SERVER time that has nothing to do with PHP, WordPress, or Site-time, the issues get’s trickier. This is unusual, because it is a time-stamp from outside PHP and WordPress, but displayed in PHP and wordpress. 🙂

Because WordFence is affected by the separate settings in both PHP and WordPress, both of which are completely unaffected by the Servers (Linux’s) ideas of its timezone. 🙂

So one need to pick one’s poison here, since there is no clean and easy way to “bypass” both WordPress and PHP’s notions of time/timezone. They do not mean it to be bypassed 🙂

The only sure way to always show the same file-time, is to have server, PHP, and WordPress/site timezones synch’ed up. But that is rarely possible for anyone, since you might buy hosting in Austin, Texas (like hostgator running all their servers in their timzezone), but you are using it for a site that is “pretending” to be running in a California or New York timezone.

To show “Server time”, WordFence would have to acquire the local Server timezone (from outside PHP), and then either (temporarily) set the PHP timezone using date_default_timezone_set (No please, Ugly,. don’t do it, bad 🙂 ).
Or the better way: Figure out the SERVER’s notion of timezone, and then use the DateTime PHP class to set a DateTime variable in that timezone. The DateTime class can then be used to convert the filemtime() results you find into human Server timestamps.
Bypassing the standard “date() call, which is too dumb to know anything but PHP time.

Another complexity is, that even if implemented. Linux and PHP have slightly different syntax for Timezone strings. Meaning that in some timezones, you will get support calls because trying to set the Unix formal timezone in PHP will produce errors. 🙂

Dates/Times are so much fun, Eeh?
Something that conceptually simple, yet so tricky to handle.