I understand a 'date' has both 'local' fields (i.e. in local timezone) and 'db' fields (i.e. UTC/GMT) and that when one is initialized, the other is automatically calculated using the function 'date_set_date'.

If the above assumption is correct, then I believe there is a bug in date.inc. Here is how I tested and corrected:

Testing environment

  • Drupal 5.7
  • PHP 5.2.0-8+etch11
  • Zend Engine v2.2.0
  • Debian Linux 4.x
  • MySQL database 5.0.32

Timezone on my server:

# cat /etc/timezone
Europe/Luxembourg

which is +2h (east) from UTC

# date '+%:z'
+02:00

The server is configured to use UTC

# cat /etc/default/rcS | grep UTC
UTC=yes

Testing procedure

Create a block in Drupal for testing purpose (input format=PHP code):


date_load('date.inc');

$now[unix] = time();
$now[year] = idate('Y', $now[unix]);
$now[month] = idate('n', $now[unix]);
$now[day] = idate('d', $now[unix]);

print_r($now);

$date[unix] = mktime(0,0,0,$now[month],$now[day],$now[year]);
print_r($date);

$dateapi=date_make_date($date[unix],'Europe/Luxembourg','db',DATE_UNIX);
print_r($dateapi);

Here is the output with date_api 5.x-1.8

Array ( [unix] => 1217889934 [year] => 2008 [month] => 8 [day] => 5 ) Array ( [unix] => 1217887200 ) stdClass Object ( [db] => stdClass Object ( [timestamp] => 1217887200 [iso] => 2008-08-04T22:00:00 [parts] => Array ( [seconds] => 0 [minutes] => 0 [hours] => 22 [mday] => 4 [wday] => 1 [mon] => 8 [year] => 2008 [yday] => 216 [weekday] => Monday [month] => August [0] => 1217887200 ) ) [local] => stdClass Object ( [timestamp] => [iso] => [parts] => [timezone] => [offset] => ) ) 

Problem: 'local' fields are not populated
Cause: date.inc, lines 297-301 test for non empty 'local' fields instead of non empty 'db' fields. Since 'local' fields are empty to start, the conversion is never made.

Here is the output with patched date_api 5.x-1.8

Array ( [unix] => 1217889978 [year] => 2008 [month] => 8 [day] => 5 ) Array ( [unix] => 1217887200 ) stdClass Object ( [db] => stdClass Object ( [timestamp] => 1217887200 [iso] => 2008-08-04T22:00:00 [parts] => Array ( [seconds] => 0 [minutes] => 0 [hours] => 22 [mday] => 4 [wday] => 1 [mon] => 8 [year] => 2008 [yday] => 216 [weekday] => Monday [month] => August [0] => 1217887200 ) ) [local] => stdClass Object ( [timestamp] => 1217894400 [iso] => 2008-08-05T00:00:00 [parts] => Array ( [seconds] => 0 [minutes] => 0 [hours] => 0 [mday] => 5 [wday] => 2 [mon] => 8 [year] => 2008 [yday] => 217 [weekday] => Tuesday [month] => August [0] => 1217894400 ) [timezone] => Europe/Luxembourg [offset] => +7200 ) ) 

Conclusion: with the patch 'db' fields and 'local' fields are populated as expected.

Patch to follow in a comment.

CommentFileSizeAuthor
#1 fixing_date_set_date-291165-1.patch804 bytespete-drupal
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pete-drupal’s picture

Patch attached

pete-drupal’s picture

Assigned: pete-drupal » Unassigned

Unassigning issue

KarenS’s picture

Status: Needs review » Closed (won't fix)

I'm not making changes to the 5.1 version. I'm officially recommending you move to the 5.2 version now. If you have problems in that version you can check for existing issues or add new ones. Feature requests are now getting posted to the D6 version to be back-ported to 5.2.