I couldn't find this problem posted anywhere, so hopefully this isn't already discussed.

I've tested this in both Windows Live Writer and Scribefire. Windows live writer gives you a checkbox to set the publish date. Scribefire appears to do it by default.

Either way, the date that gets set on the server ends up as GMT/UTC, when it should be whatever the user sent (Example: I'm pacific time (-8:00) so a time of 2pm ends up displaying on the server as 10pm).

First, in blogapi.module, there is _blogapi_mt_extra. Here, the $struct['dateCreated'] value is the one that's getting sent by these programs. The value is already in GMT.

When it gets to:

if ($struct['dateCreated']) {    
    $node->date = format_date(mktime($struct['dateCreated']->hour, $struct['dateCreated']->minute, $struct['dateCreated']->second, $struct['dateCreated']->month, $struct['dateCreated']->day, $struct['dateCreated']->year), 'custom', 'Y-m-d H:i:s O');
  }

The format_date function is returning a date that is still in GMT.

Looking at format_date, it's using gmdate(), so I think the problem is there. Since I wasn't sure of unintended consequences though, I didn't want to mess with format_date, but what's happening is early in format_date, the timezone gets added (as it should), but then the gmdate function sets the time back to GMT when creating the string. If a user timezone is being used, it should probably not use gmdate.

As a temporary fix, I went back to blogapi.module and just added the timezone again (which is really a double add until the format_date function gets fixed):

// dateCreated
  if ($struct['dateCreated']) {
     
    $tzone = variable_get('date_default_timezone', 0);
    global $user;
    if (variable_get('configurable_timezones', 1) && $user->uid && strlen($user->timezone)) {
      print_to_file("\nUser->Tzone: ".$user->timezone);
      $tzone = $user->timezone;
    }
    
    $node->date = format_date(mktime($struct['dateCreated']->hour, $struct['dateCreated']->minute, $struct['dateCreated']->second, $struct['dateCreated']->month, $struct['dateCreated']->day, $struct['dateCreated']->year) + $tzone, 'custom', 'Y-m-d H:i:s O');
  }

format_date likely needs to be looked at though since it was still adding then removing the timezone value.

Comments

zdean’s picture

zdean commented

I'm having the same issue using Scribefire

rivena’s picture

rivena commented
Version: 6.9 » 6.16

I also just ran into this problem with scribefire, and my current version of drupal.

Anisa.

threeps’s picture

threeps commented

I ran into the same problem with scribefire. Jimejim, thanks for pointing to where the problem is. I think a simpler fix is to change

if ($struct['dateCreated']) {   
    $node->date = format_date(mktime($struct['dateCreated']->hour, $struct['dateCreated']->minute, $struct['dateCreated']->second, $struct['dateCreated']->month, $struct['dateCreated']->day, $struct['dateCreated']->year), 'custom', 'Y-m-d H:i:s O');
  }

to

if ($struct['dateCreated']) {   
    $node->date = format_date(gmmktime($struct['dateCreated']->hour, $struct['dateCreated']->minute, $struct['dateCreated']->second, $struct['dateCreated']->month, $struct['dateCreated']->day, $struct['dateCreated']->year), 'custom', 'Y-m-d H:i:s O');
  }

(note: difference is mktime becomes gmmktime).

This change works because mktime expects a localtime, while gmmktime expects a GMT time, which is what scribefire sends. So, for scribefire, this change works, but if other blogapi programs do not send the time in GMT, then this fix would break those programs. I haven't tested any other programs, and I'm not familiar with the API, so I don't know if this change will work for all programs or whether we need a test for which program is using the API.

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.