timestamp issue

[ZappoMan]

Has anyone seen a problem with time stamps and auto-save in the 2.6 and 2.6.1 versions of mu?

What I am seeing is that a post will get stamped with the time zone of the server (in my case GMT) and does not respect the blog's GMT offset.

I haven't been able to track this down, but it's really annoying me.

I was hoping it was a 2.6 bug that was fixed in 2.6.1 but it seems to still happen to me in 2.6.1... now, it's certainly possible that some other plugin of mine is messing this up... so I'm hoping someone else can tell me if they see this also.

Thanks in advance.

[ZappoMan]

me thinks it is a plugin!

I just tested again with the plain jane 2.6.1. code and it doesn't appear to have this issue.

[drmike]

Any idea which plugin was causing the issue?  I'm sure as soon as I mention it in passing on my own support forums, someone will speak up and let me know they're having the problem.

One of my biggest pet peeves is how theme designers hard code the timestamp output into their themes instead of using the settings within wp.

[ron_r]

I was testing some code here tonight and changed the blog's time zone. After that I changed the timestamp on a post. The post_date_gmt was still being saved with the old offset.

[ZappoMan]

One of my biggest pet peeves is how theme designers hard code the timestamp output into their themes instead of using the settings within wp.

Interesting clue!

I am now looking to see if this is actually related to themes displaying the timestamp wrong! Thanks for the tip!

[ZappoMan]

Jeez... I am going crazy...

Now I stripped 2.6.1 down to the bare minimum and I think this is still happening...

Here's what I see:

1) Start writing a post
2) Auto-save happens--
    sets post_modified and post_modified_gmt to the expected values.
    sets post_date and post_date_gmt to "0000-00-00 00:00:00". (hmmm, that seems a little odd!)

3) Click Publish:
    sets post_modified and post_modified_gmt to the expected values.
    sets post_date and post_date_gmt to something CRAZY!

It looks like the post_date = post_modified_date -16 hours?!?! and post_date_gmt = post_modified_gmt -16 hours?!?! I mean WTF?!?!!!!

That's crazy...

Note: my local time is set to GMT -7... so there's no way to get this to add up...

Thoughts?!?!

At this point, the only "plugins" I'm running are multi-db... and a custom authentication plugin...

[drmike]

    sets post_date and post_date_gmt to something CRAZY!

It looks like the post_date = post_modified_date -16 hours?!?! and post_date_gmt = post_modified_gmt -16 hours?!?! I mean WTF?!?!!!!

I was looking at the math as well.  Only thing I can come up with would be it's subtracting a day, adding in the 7 hours and then another hour for daylight savings but this isn't the time of year for that anyway.

I'd open up a trac ticket.

If you really want to debug, I'd start dropping in echos in a number of places just to display the timestamps as you write.  That would be a pain though.

[ZappoMan]

Well, it looks like this might only happen in the 2.6 code... or at least now, after stepping away from the keyboard and going to sleep... the problem does not appear to be happening in the 2.6.1 code base.

I had apache pointing to the wrong directory last night when I thought it was running 2.6.1 it was actually running older code.

So, hopefully, this is not an issue anymore.

[ron_r]

Where is the server located GMT -7 as well?

[ZappoMan]

LMAO!!!

You guys are gonna love this! Since you all told me to stay away from it...

It turns out this problem was caused by the xcache version of object-cache.php.

Once I got rid of that, all my problems went away. This also explains why it kept thinking it existed in the 2.6.1. code base as well.

Argh!

[Luke]

That's interesting.

Were you having the "site admin" link problem with it? Every time I dropped in the xcache object cache, it wouldn't display the site admin link.

I think we're going to end up with the memcached version, once things get settled.

[ZappoMan]

Actually, I've never seen this site admin problem.

Trent has explained it to me... but on my systems I always get the site admin menu appropriately even with xcache running.

What are you waiting for with memcached? Are there known issues with that?

I was just checking out APC as well... I finally pulled xcache because it was segfaulting way too much especially with the 2.6.1 codebase.

[Luke]

Strange, as I've never had the site admin menu with the xcache based object cache.

As for memcached, it's not issues, it's timing. A few other things have to happen first, and then once those are cleared, it will be added.

Probably 2 servers with 8G of RAM to start.

[trent]

memcached looks incredibly easy to setup, but what % of memory would most people give it compared to available memory on a box?   As well, do you have to specify the port it is working on or should it use the default port?   Can it work with xcache or an "either/or" type of thing?    Ryan B wrote the plugin for object-cache and memcached correct?   Does it work with the recent versions of WPMU and WP?

Trent

[Luke]

memcached looks incredibly easy to setup, but what % of memory would most people give it compared to available memory on a box?

You wouldn't want to run memcached on the same box as anything else. We're getting boxes with bare minimum processors and disks, and a ton of RAM.

As well, do you have to specify the port it is working on or should it use the default port?

Whatever you prefer. We'll be using the default, as the boxes won't have a publicly addressable IP.

Can it work with xcache or an "either/or" type of thing?

It replaces the WP object class, but you could still run xcache on an individual box to cache compiled PHP pages.

Ryan B wrote the plugin for object-cache and memcached correct?

Yes.

Does it work with the recent versions of WPMU and WP?

Yep.