• I changed the time_difference in my options to +2, but the time still stays the same. It should show 12:28pm, but it shows 10:28am instead. I also tried +6 (GMT+6), but that didn’t work either. o_O
    *** I’m using the new beta that I downloaded from cvs. ***

Viewing 11 replies - 1 through 11 (of 11 total)
  • Try taking out the ‘+’ sign. You just want the bare number (though, you <b>would</b> use a minus sign if you wanted to times to be earlier).

    I’ve got the ‘+’ sign on mine with no (obvious) problems. Should I leave it alone, or do as you suggest?

    Thread Starter codergurl

    (@codergurl)

    It still doesn’t work.

    codergurl: Just to make sure we’re on the same page… Changing the time_difference setting in the options screen won’t affect the time for postings already in your blog. Only for postings you make after you change the setting.
    Is that the problem?

    Thread Starter codergurl

    (@codergurl)

    Yes. Yesterday after I posted I decided to look through the code that posts the entries and realized that that was what the problem was. It’s not that big of a deal though I guess.

    Gurk. Looking into it….

    Okay, I think I’ve tracked down the rss problem to a logic error in the Conditional GET support. But I’m about to leave my computer. If I don’t fix it tonight, I’ll get it done first thing in the morning. In the meantime, you can fix it by looking for this:
    <b>if (($slast?($slast == $clast)…)){</b>
    And changing it to this:
    <b>if (false && ($slast?($slast == $clast)…))</b>
    That will disable Conditional GETs.

    Okay, I’ve just committed a proper fix into CVS for the Conditional GET checking. The problem occurred when neither the “If-Modified-Since” nor the “If-None-Match” headers occurred. The logic says that you return a “304 Not Modified” return if *either* of those headers sent by the client matches what the server expects. But if *both* headers are sent by the client, then *both* must match. I tried to short circuit the logic, but I failed to take into account what happens when neither header is sent by the client. My faulty logic was returning a 304 in that case, which was bad. Because if the client didn’t send those headers, it didn’t have the information in the first place. So, telling it that it hasn’t been modified didn’t do much good, did it?
    Anyhow, all fixed up now 🙂

    While we’re on the time subject, is it possible to get WordPress to allow decimals in the offset? My webhost is hiding m virtual server who knows where and I don’t have proper permissions via SSH to change the time on the server. If only I could go -1.5 in WordPress I think everything would be close enough to kosher for me.
    Of course this is only a minor problem for me, but maybe someone else is having similar issues. Awesome work on the latest release guys!
    -Syntax
    http://www.wantmoore.com

    Hi Justin,
    The latest beta version does allow fractional time differences. I’ve just tested it and it has no problems supporting that. I tried both -1.5 and (+)5.5
    Mike

    Nice! Thanks Mike!

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘time_difference..no change’ is closed to new replies.