Thread

Thanks Lisa, I’ll play around with the Localization class.

If you could confirm that the delta between current GMT and the time stamp inserted into the exp_comments form is always 5 hours, though, I’d be your biggest fan.

Pete, the comments that are off, are they from registered users, or from non-registered?

Both, though the vast majority of our comments are from non-registered users.

Pete, when you set up the site initially, which time zone did you set it to?

EEDocs:// Localization Settings

And what are your localization setting set to?

I believe it was initially set to EST, (the install was done in fall of 2006) and, aside from changing it to GMT for a few minutes to try something for Lisa this afternoon, I think that’s where it has always been. Honestly I’m just basing that on the fact that it was set to EST today and I’ve never changed it. I can’t be sure no one else did though.

Just curious, if EE uses GMT time for all its internal dates, how can EE Control Panel settings change those internal dates?

By the way, the same effect can be seen on our dev server (on a machine in our in-office data center) and our live servers at EngineHosting for two different sites (two separate installs of EE). So I’m starting to think its just a quirk of EE; no one ever expected end users to be peering directly into the database and for whatever reason, they needed the date stored there to be time-shifted forward?? Just a bit of late night speculation on my part…

EE uses UTC based on how you have set up the server’s localization settings.  If you tell EE that the server is +8 GMT, EE will subtract 8 hours from what the server reports the current time as being and use that to adjust submitted times.  The user’s own localization setting is also taken into consideration.  Then when EE outputs dates, it reverses this to display the time in the logged in users’s own time zone.

So for EE to store UTC timestamps properly:

a) the server’s own clock and DST setting must be correct
b) you must tell EE what timezone the server is in
c) you must tell EE whether the server is observing DST
d) the user must tell EE what timezone they live in
e) the user must tell EE whether the server is observing DST

So when you change those settings, you are not changing what is stored, only how that stored timestamp is output.  And if (a) (b) or (c) were incorrect, then the dates could have been stored improperly.

If you tell EE that the server is +8 GMT, EE will subtract 8 hours from what the server reports the current time as being and use that to adjust submitted times.

So, let’s figure this out.

Only a, b, and c apply as I’m not using EE to get the date stamp out. Just doing a sql query.

Our live servers are at EngineHosting, and I’ll assume that they have the clocks set correctly. I know, I know… assumptions are always problematic!

We’ve told EE that the server is UTC-5, so EE should be adding 5 hours from what the server reports as the current time.

But its adding 10 hours. So right now, as I’m writing this, it is 15:13 GMT, but if I post a comment, the timestamp for it will be 20:13 GMT which is in the future.

But, using EE to spit out the date, this future posting date is being accounted for I guess, because I get an accurate time stamp.

Could it be that MySQL is also adjusting the time, so its getting double adjusted? MySQL’s timezone setting is set to SYSTEM. *checks* No, probably not, the comment_date field is an integer.

On our second site, where DST is set to Yes, the gap is 12 hours. Which at least indicates consistency.

I suppose at this point I suppose this has become an academic discussion. I can adjust for this temporal drift. 😊 At some point I’ll tear into the source and hopefully get my head around what’s happening.

We do not store MySQL dates as we did not want to add a third system in for conversion.  The date is calculated with PHP to a Unix timestamp and saved as a MySQL integer.  Your server’s time isn’t correct for EngineHosting, though.  Their servers are in CST, UTC-6.  DST should be off (until this coming Sunday).

But its adding 10 hours. So right now, as I’m writing this, it is 15:13 GMT, but if I post a comment, the timestamp for it will be 20:13 GMT which is in the future.

That’s adding 5 hours, not 10, and sounds correct, at least for the server setting you have.

Perhaps it could be better demonstrated with a code sample.  In a PHP enabled template, place the following.

<?php
global $LOC;

echo "Now (UTC): {$LOC->now} - ".date('m-d-y H:i', $LOC->now)."
\n";
echo "Localized: ".date('m-d-y H:i', $LOC->set_localized_time())."
\n";
?>

$LOC->now is used on database inserts for submission timestamps is UTC, and will only be correct if your server localization settings are correct.  Note that I’m using date() above and not gmdate(), because $LOC->now is already a GMT date.  If you use gmdate(), the server will assume that the timestamp is localized and based on its internal settings will output a UTC date.  The following illustrates:

<?php
global $LOC;

echo "Now (UTC): {$LOC->now} - ".date('m-d-y H:i', $LOC->now)."
\n";
echo "GMT: ".time().' - '.gmdate('m-d-y H:i', time())."
\n";
?>

The formatted dates should match, and the timestamps will not, unless the server is at UTC.

But its adding 10 hours. So right now, as I’m writing this, it is 15:13 GMT, but if I post a comment, the timestamp for it will be 20:13 GMT which is in the future.

That’s adding 5 hours, not 10, and sounds correct, at least for the server setting you have.

Sorry, I should’ve been more clear. It’s adding 10 hours to ‘local time’ (EST, what the server is set at). In other words, at the time I was writing that post, it was 10:13 EST, 15:13 GMT, and the timestamp being inserted into the database was 20:13 GMT.

But I think I’m finally getting it. So you’re deliberately writing the timestamp 5 hours into the future so when it “backs up” to local time, you get an accurate time, in GMT.

In the meanwhile, I’ll change the server settings to be -6 UTC and will use the admin account’s localization settings as the master site default. That way, if I’m understanding correctly, the server will be set correctly but comments will still display EST (the admin settings) for non-registered users. Since we do business in EST we’d like that to be the ‘default’ time for the site.

Almost there, Pete.  We are storing the accurate GMT time in the database ($LOC->now) - the offset dance is done on output to display a correct local time based on that date.  Double check ALL of the localization settings, including your own account’s settings.  You should be getting a GMT date stored in the database, not a 5 hour offset applied twice.

So far no luck finding an errant setting.

I’ve stopping mucking with the settings for now since the comment timestamps were jumping around on the front end. Figured I’d better wait to make those changes late at night when things are quiet 😊

System Prefs => Localization Settings is set to GTC-5 (will change that to GTC-6 tonight), DST No.

My Account is set properly (UTC-5, ie ET where we are located) and I’ve switched off the “Use this member’s localization settings as the master site default” (for now, will turn that on tonight too)

The admin account’s localization is set right as well (UTC-5)

I’ve looked in Member Groups and Weblog Preferences looking for other localization settings but so far have come up empty. Even checked the config file, but nothing there.

Any other place I should be checking? Thanks!

You’re checking all the right places.  What do you mean by “comment timestamps were jumping around on the front end”?

When I changed the server settings to UTC-6, the time stamps on the comments, as displayed by EE (that is, for visitors to the site itself), jumped ahead 1 hour (which was to be expected I believe). This left comments with time stamps ahead of our local time. I thought I could control that by using my account’s “Use this members localization settings as the master site default.” but they didn’t work immediately. It was probably a caching issue, but rather than have to explain to half a dozen web site editors why the comments were suddenly future dated, I just put everything back and decided to make these tweaks late at night when I didn’t have the whole staff staring at the site. 😊 Self-preservation, y’know.