bug in get_calendar() or I have a pretty freaky php install

It appears to be worse. At least on my server, the calendar display is a mess for wny setting other than the week starting on a Sunday. Since I can?t be the first WordPress user to change from Sunday I imagine the problem might be something with my server. If it was a proper WordPress bug it would have been caught by now.

So, what can I check? Any suggestions?

Furhter details suggest it IS a problem with WordPress. At least as it behaves on my server.
(An Ubuntu 8.10, nginx, php5.2.4 apt package + eaccelerator)

in any plain old php file on my server:
date('w', mktime(0, 0 , 0, '06', 1, '2009')) // aka: date('w', $unixmonth)
will return 1 since june of 2009 begins on a Monday (At least according to Google Calendar).

Inside WordPress is returns 0. I echoed it on the line just above where the padding is calculated, just to check)
No idea why, though.

I deactivated all (4) plugins I have but still the same result.

Ok, boring one-man conversation but I can’t let this go and just go to bed.

Here is the answer fully and truly put to rest.

from php.net

Warning
Please do not use any of the timezones listed here (besides UTC), they only exist for backward compatible reasons.

Besides various named cities around the world WordPress lists a number of general timezones relative to UTC. WordPress installed to UTC and I simply selected one down for UTC+1 which is my timezone… except that the values for the UTC-relative timezones are the “Etc/GMT” kind listed on the linked page. If I scroll up to “Stockholm” (Sweden) instead… weekdays are calculated correctly.

So, don’t use the “general” timezones… why they are listed is not for me to guess.

I am having the same problem you described, but your fix did not appear to work for me. My site is at timjpriebe.com if you’d like to see the widget messed up.

Tracked it down to line 1117 and 1138 in general-template.php. date(‘w’, $unixmonth) is returning the wrong value.

$unixmonth is set in line 1007, and appears to be correct, though I can’t tell for sure.

Okay, figured it out. The php configuration had to have the same timezone setting as WordPress. In my case, I did not have direct access to php.ini, so I set it in wp-config.php by adding the following line:

date_default_timezone_set('America/Chicago');

Substitute whatever timezone you have set up in WordPress.

Okay, final post on the subject for the evening. Can’t WP read in the timezone and dynamically override the PHP settings so this sort of miscalculation doesn’t happen?

Yeah that solve doesnt fix it for me.
php.ini –
[Date]
; Defines the default timezone used by the date functions
date.timezone = ‘America/Los_Angeles’;

Which is the same as what I put in the settings and the colspan is still out of whack.

Which the wordpress one should overwrite in the first place since no matter the hosting the person who owns the wordpress will want it to be in their timezone now matter where it’s hosted.

Has this problem been solved?
I sort of “hacked” the general-template.php by adding my timezone.
I am in Rio (UTC-0300 or -0200 during the summer). I changed line 1008 to read:

$unixmonth = mktime(4, 0 , 0, $thismonth, 1, $thisyear);

Where I add <4> hours to the time. This seems to have “solved” it.