Thread

There are a few places where localization settings can be set within the CP.

I am trying to figure out what you have set, and what you don’t.

I have escalated this post, and will let you know when I hear something from the Dev team.

Thanks for your patience. We have been fairly busy after the new year 😊

There are a few places where localization settings can be set within the CP.

I am trying to figure out what you have set, and what you don’t.

I have escalated this post, and will let you know when I hear something from the Dev team.

Thanks for your patience. We have been fairly busy after the new year 😊

but if you read through the thread - you would understand that localization is not central to my issue.

What is central to my issue is that the unix timestamp being inserted with my posts is wrong. No amount of localization toggling is going to change that.

MySQL gives the correct time stamp. raw PHP code does. Invision Power Board does. My own php code. EE doesn’t.

It sounds like EE is working correctly- it’s just the format of the time in the database that you’re wondering about?  If so- you can take a look at the localization class- EE enters the entry_date as $LOC->now- which is calculated via:

if ($now == '')
        {
            $now = time(); 
        }
            
        $time =  @mktime(    gmdate("H", $now),
                            gmdate("i", $now),
                            gmdate("s", $now),
                            gmdate("m", $now),
                            gmdate("d", $now),
                            gmdate("Y", $now),
                            -1    // this must be explicitly set or some FreeBSD servers behave erratically
                            );

That’s a wee bit simplified- but you can see:

$this->server_now     = time();
$this->now        = $this->set_gmt($this->server_now);

And then set_gmt is mostly mktime/gmdate.

Does that clarify things?  Or make them worse?

It sounds like EE is working correctly- it’s just the format of the time in the database that you’re wondering about?  If so- you can take a look at the localization class- EE enters the entry_date as $LOC->now- which is calculated via:

if ($now == '')
        {
            $now = time(); 
        }
            
        $time =  @mktime(    gmdate("H", $now),
                            gmdate("i", $now),
                            gmdate("s", $now),
                            gmdate("m", $now),
                            gmdate("d", $now),
                            gmdate("Y", $now),
                            -1    // this must be explicitly set or some FreeBSD servers behave erratically
                            );

That’s a wee bit simplified- but you can see:

$this->server_now     = time();
$this->now        = $this->set_gmt($this->server_now);

And then set_gmt is mostly mktime/gmdate.

Does that clarify things?  Or make them worse?

It doesn’t address the problem at all and I’m not sure how to explain it any simpler.

There is a table called exp_weblog_titles

in that table is a field called entry_date

that field stores a unix timestamp. Supposedly, this timestamp is GMT/UTC time. Correct? The time stamp stored in this field is 6 hours in the future (with respect to GMT). That strikes me as being very bizarre. The formatted time stored in the “edit_date” field is correct with respect to the server’s native time zone. The “day” field takes on the day of the wrong timestamp.  That means any post I make between noon and midnight - gets stored in the “day” field as today’s date +1 (6 hour CST server offset plus this mystery 6 hour offset.

This causes errors in the archives.

Here is an example (note this will only work for today, then I have to change the query):

http://www.sabrespace.com/buffalo-sabres/news/

I have the query set to show 8 days. The last entry:

Vanek back in the lineup

was made at 12/26/09 01:55 pm.

but then go here:

http://www.sabrespace.com/buffalo-sabres/news/2009/12/

and look at 12/26. There are two more entries in there that don’t get listed in the daily view. What I have found is that it seems the daily view of the archives uses the “day” field of the exp_weblog_titles table. But because of this 6 hour time shift - the “day” entries all get screwed up.  So, in this case That entry has a “day” setting of 27, but the other entries have 26 - despite all of them being posted on the same day. The show daily function stops when it gets to that entry because including the others would make it 9 days and not 8.

As another example, when I use cvsgrab to import entries - I have to input a 12 hour time offset in order for my dates to come out correctly, instead of the expected 6 hours.

Does that clear things up? See my previous posts for specific timestamps, their human readable forms, and when the posts were actually made.

Hrm- k- what version of php are you running (forgive if answered- thread has gotten thick).  And can you double check- even though the server may be in Texas, what timezone is the server configured to run on?  Could differ and want to be dead sure.

My system time is indeed correct on the server.

[root@www /]# date
Sun Jan 3 13:36:04 CST 2010

php 5.2.9

OK- I think 2 things are going on- given the generally correct results.

1.  Day/week/month are not localized- so regardless of issue #2, what is pulled back won’t vary based on the user’s localization settings.  It’s going to work based on the ‘date’ in the database. 

2.  The entry date is offset based on the server timezone.  So the date in the database is not always (depending on server tz) going to be gmt ‘now’ (see set_localized_offset())- it’s then adjusted based on that same offset when it’s pulled out for use.  Thus it displays correctly.  Which it sounds like it’s doing.  (Note that in 2.0 those dates are adjusted to a true gmt- at which point they’d give you the results you expect.)

So it sounds like it’s working as expected- the biggest issue being that the d/m/w isn’t localized- including the reversal of that server tz adjustment.

I’m wondering if we might work around it w/some creative use of the start_on parameter.  I wouldn’t recommend trying to alter the way dates are handled- particularly given 2.0 alters that and expects them to be in there adjusted for server tz.  But start_on could give a finer grained control and might do the trick.

OK- I think 2 things are going on- given the generally correct results.

1.  Day/week/month are not localized- so regardless of issue #2, what is pulled back won’t vary based on the user’s localization settings.  It’s going to work based on the ‘date’ in the database. 

2.  The entry date is offset based on the server timezone.  So the date in the database is not always (depending on server tz) going to be gmt ‘now’ (see set_localized_offset())- it’s then adjusted based on that same offset when it’s pulled out for use.  Thus it displays correctly.  Which it sounds like it’s doing.  (Note that in 2.0 those dates are adjusted to a true gmt- at which point they’d give you the results you expect.)

So it sounds like it’s working as expected- the biggest issue being that the d/m/w isn’t localized- including the reversal of that server tz adjustment.

I’m wondering if we might work around it w/some creative use of the start_on parameter.  I wouldn’t recommend trying to alter the way dates are handled- particularly given 2.0 alters that and expects them to be in there adjusted for server tz.  But start_on could give a finer grained control and might do the trick.

Generally correct? Are you serious? I just outlined several things that no one would ever consider to be correct. Let’s go through this one by one.

1. “Day/week/month are not localized.” That’s fine I suppose. It appears some sorting code is based off of this like the problem I’m experiencing: display_by=“day” limit=“2”. When the day is wrong. Grossly wrong. It affects the display.

2. This is just wrong. My server time is set correctly. GMT -6 CST (Texas). The entry in the database gets WRONGLY CONVERTED to GMT +6 Bangladesh. There is nothing you can say to tell me that timestamp is correct in any way shape or form. Bangladesh? Seriously? Just because EE is capable of undoing this error when making the time human readable - it doesn’t make it “generally correct”. This error exacerbates #1 and makes rountine parameters like “display_by=“day” almost unusable.

I imported 21,000 items over 8 years and was forced to give them a Bangladesh timestamp in order to make them display correctly in certain situations (some situations they won’t). What happens in EE 2.0?

You stated this behavior is correct, yet the team saw fit to change the correct behavior to a “more correct behavior” and make them GMT 0.

I just checked my test installation of 2.0. The timestamp on a new post is exactly right - GMT 0 as expected (not GMT Bangladesh). The “day” field says today - as desired (note that it IS localized. Otherwise it would have put the 8th down)!

I run a daily news site. “Daily” matters to me… not “sorta daily give or take 12 hours”.

3. While there may be a work around by using different parameters - I hope you see that one shouldn’t need more fine grain control over “daily”. “Start on” doesn’t work for me because I want that page to display the last two days that have news entries - not the last 48 hours. display_by=“day” limit=“2” is supposed to do that. But it doesn’t.

So, I guess the questions are:

1. Will there be an update script available that will correct the inherent 1.6.8 timestamp mess as people move to 2.0?

or

2. Will all our old posts be read as being posted a server offset time prior to their original posting date and time?

1. “Day/week/month are not localized.” That’s fine I suppose. It appears some sorting code is based off of this like the problem I’m experiencing: display_by=“day” limit=“2”. When the day is wrong. Grossly wrong. It affects the display.

Correct.  There are some methods that can be employed to localize the display_by= usage, but performance is a factor.  An acceptable compromise has not yet been reached.

1. Will there be an update script available that will correct the inherent 1.6.8 timestamp mess as people move to 2.0?

Yes.  Ultimately, in 1.x, since the display is unaffected, it will not be addressed in that version.  System wide we simply felt it was too large of a change to make on an incremental release, as it touches not only nearly every 1st party table, but 3rd party tables as well.  We agree with you that it’s wrong to have those timestamps in the database, which is why we’ve addressed it.

When you upgrade from 1.x to 2.x, all timestamps are modified so that they are true UTC timestamps.