Week number in month view
chrissearle - January 25, 2007 - 14:27
| Project: | Calendar |
| Version: | 5.x-1.4 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Just noticed this - I have january open in month view. It has the following weeks (reading down the left of the table)
02
03
04
05
05
So - whats up with the last row?
#1
I found the week numbers a bit distraction, myself. So I hid them in my custom theme:
td.week {
display:none;
}
#2
Possibly so - but we actually use the week numbers - so hiding them isn't going to help
#3
I can't replicate this. The weeks appear fine for me. I've made a number of commits today. Can you confirm there is still a problem after updating to latest version (either get it from cvs or wait until tomorrow to pick up a tarball with the latest changes.) If you still have a problem after that, can you post a screenshot and an export of your view?
#4
OK - Just tried with the 5.x-1.x dev release.
Here's the export (screenshot of march attached - same issue - but no entries):
$view = new stdClass();
$view->name = 'calendar';
$view->description = 'Calendar';
$view->access = array (
);
$view->view_args_php = '';
$view->page = TRUE;
$view->page_title = 'Calendar';
$view->page_header = '';
$view->page_header_format = '1';
$view->page_footer = '';
$view->page_footer_format = '1';
$view->page_empty = '';
$view->page_empty_format = '1';
$view->page_type = 'calendar';
$view->url = 'cal';
$view->use_pager = FALSE;
$view->nodes_per_page = '100';
$view->menu = TRUE;
$view->menu_title = 'Calendar';
$view->menu_tab = FALSE;
$view->menu_tab_default = FALSE;
$view->menu_tab_weight = '0';
$view->sort = array (
);
$view->argument = array (
array (
'type' => 'calendar_year',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
array (
'type' => 'calendar_month',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
array (
'type' => 'calendar_day',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
array (
'type' => 'calendar_week',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
);
$view->field = array (
array (
'tablename' => 'node',
'field' => 'title',
'label' => '',
'handler' => 'views_handler_field_nodelink',
'options' => 'link',
),
array (
'tablename' => 'node_data_field_start',
'field' => 'field_start_value',
'label' => '',
'handler' => 'content_views_field_handler_group',
'options' => 'default',
),
array (
'tablename' => 'node_data_field_date',
'field' => 'field_date_value',
'label' => '',
'handler' => 'content_views_field_handler_group',
'options' => 'default',
),
);
$view->filter = array (
array (
'tablename' => 'node',
'field' => 'status',
'operator' => '=',
'options' => '',
'value' => '1',
),
array (
'tablename' => 'node',
'field' => 'type',
'operator' => 'OR',
'options' => '',
'value' => array (
0 => 'in_out',
1 => 'meeting',
),
),
);
$view->exposed_filter = array (
);
$view->requires = array(node, node_data_field_start, node_data_field_date);
$views[$view->name] = $view;
#5
See my comment at http://drupal.org/node/111947. You don't need the week argument and it is going to cause odd behavior.
#6
Still seeing the problem - the edited view export
$view = new stdClass();$view->name = 'calendar';
$view->description = 'Calendar';
$view->access = array (
);
$view->view_args_php = '';
$view->page = TRUE;
$view->page_title = 'Calendar';
$view->page_header = '';
$view->page_header_format = '1';
$view->page_footer = '';
$view->page_footer_format = '1';
$view->page_empty = '';
$view->page_empty_format = '1';
$view->page_type = 'calendar';
$view->url = 'cal';
$view->use_pager = FALSE;
$view->nodes_per_page = '100';
$view->menu = TRUE;
$view->menu_title = 'Calendar';
$view->menu_tab = FALSE;
$view->menu_tab_default = FALSE;
$view->menu_tab_weight = '0';
$view->sort = array (
);
$view->argument = array (
array (
'type' => 'calendar_year',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
array (
'type' => 'calendar_month',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
array (
'type' => 'calendar_day',
'argdefault' => '2',
'title' => '',
'options' => '',
'wildcard' => '',
'wildcard_substitution' => '',
),
);
$view->field = array (
array (
'tablename' => 'node',
'field' => 'title',
'label' => '',
'handler' => 'views_handler_field_nodelink',
'options' => 'link',
),
array (
'tablename' => 'node_data_field_start',
'field' => 'field_start_value',
'label' => '',
'handler' => 'content_views_field_handler_group',
'options' => 'default',
),
array (
'tablename' => 'node_data_field_date',
'field' => 'field_date_value',
'label' => '',
'handler' => 'content_views_field_handler_group',
'options' => 'default',
),
);
$view->filter = array (
array (
'tablename' => 'node',
'field' => 'status',
'operator' => '=',
'options' => '',
'value' => '1',
),
array (
'tablename' => 'node',
'field' => 'type',
'operator' => 'OR',
'options' => '',
'value' => array (
0 => 'in_out',
1 => 'meeting',
),
),
);
$view->exposed_filter = array (
);
$view->requires = array(node, node_data_field_start, node_data_field_date);
$views[$view->name] = $view;
An interesting one - if I navigate to march then click on week it goes to cal/2007/W13
and I see both week 13s - see attached. This applies to every month - always have the week number repeated twice at the end - am using March for screenshots since the site is an intranet and March has no entries
#7
I still can't replicate this, but I have an idea what might cause this problem. What is the first day of your week in your site settings (from the screenshot I assume it is Monday)? What is your site timezone? What is your own user settings timezone? What timezone are you using for your dates? What is the timezone of your server (especially if it is different than your site timezone)?
#8
OK - monday is start day of week.
Server runs as GMT at system level.
Site timezone is +0100
Personal timezones are disabled.
All dates are shown in site timezone.
I have a second site that is showing the same issue (so that proves its not a php4 vs php5 issue). That site I can give access to - I can create an admin account on it for you if you like - but that would have to be sent private - let me know if that will help.
#9
I have this same problem showing up. I'm also in the GMT +1 timezone. I have user timezone disabled.
#10
correction to my previous comment, I am in the GMT +0000 timezone.
#11
I committed fixes yesterday to the handling of week info that I believe will fix any problem that is still outstanding. You can reopen if not.
#12
Sorry :(
I updated to calendar 5.x-1.4 at the weekend.
The weeks for March are showing: 10, 11, 12, 13, 13.
Start of week - monday. System clock GMT. Site time CET. No user configurable zones.
Oh - and I also noticed that after the upgrade all types on the calendar got the same colour bar (prior to this each content type got a different colour) at the top of the entry (this in Garland).
#13
I'm still getting reports of problems with the week numbers when Monday is the first day of the week, but I can't replicate them. On my system the week numbers are fine whether I set the system to start on Sunday or Monday, so I'm having trouble figuring out what is different that is causing the problems for others. I'll keep investigating, but have no ideas yet.
#14
My only idea so far, did you also update to the latest version of the Date module? There are fixes in the Date API that could be affecting this.
#15
Yes - I updated Calendar and Date at the same time.
I've not dug in to Calendar - but - if you can give me a clue of where in the code I should start looking I can start adding in debug - calendar is perhaps not the simplest module to get into :)
#16
Just an update, I've been working on chrissearle's site to see if I can replicate his problem and even when I mirror exactly the way he has his site set up, my local copy works fine and his site doesn't. It's starting to look like there is some sort of environment issue causing this, but can't tell yet.
#17
Am wondering what it could be.
I have both mysql 4 and 5 based sites and php 4 and 5 sites doing this. So - it sounds like it may be environmental.
What is odd is that it does it on all sites I have calendar installed on - thats at least 7 machines now!
I do wonder what locale Karen's web browser is running under.
I've sent Karen links where she can grab my sites dir, my modules list and the db dump - maybe that will help us show that it is environmental or not. If with my db dump and sites dir the error does not turn up it _has_ to be environmental. However - if with that db and sites setup it turns up for Karen at last then 1) it probably isn't environmental and 2) at last she has a debuggable instance :)
Crossing my fingers ;)
#18
It is definitely environmental. I dumped Chris's database and files into a new installation on my site and it worked fine for me.
I'm using mysql 4.1.14 and he is on mysql 5.0.32, I'm using php 5.0.5 and he's using php 5.2.0-8. Both mysql and php implemented new methods for handling timezones between the version I'm using and the version he is using, which leads me to think version differences are the issue (or at least one of the issues) except that he says he's seeing this on php4 and mysql 4 sites, too. My test environment is Apache/2.0.54 (Win32) and his is Apache/2.2.3 (Debian), so that's another possible contributing factor.
I have not yet been able to come up with any way to replicate the behavior he is getting on his site (an extra copy of one week number in the month view, and a title that is off by one week, and an occasional double week in the week view). His site timezone is set up for 1 hour greater than GMT, and an extra hour added to the end date for a week could easily confuse the system enough to get the end of one week and the start of the next week wrong, which is what I suspect is happening.
Anyway, no solution yet :-(
#19
Trouble is - I also have this on a site running on php 4.3.10 and 4.0.24
So - know diffs are
Karen vs me:
Mysql 4.1.14 vs 5.0.32 (but here 4.0.24 is also failing)
php 5.0.5 vs 5.2.0-8 (but here 4.3.10 is also failing)
Apache/2.0.54 (Win32) vs Apache/2.2.3 (Debian)
Hmm - OS and apache version?
Anyone else having this issue - can you state what OS, MySQL version and PHP version you are on?
Didn't get time tonight - but I'm going to test my db on a Mac install (not got windows available)
I would also like to take the chance to publicly thank Karen for the level of effort she's putting in - I know just how frustrating a non-reproducible bug is to track down.
#20
The 4.3.10/4.0.24 with the issue is running under apache 1.3.3 - so that suggests that the apache version isn't an issue.
Still - all the servers I have that are showing the issue are linux (and debian at that - using the debian php packages). Looking forward to tomorrow - when I get to try it under OS X (will probably use MAMP).
#21
After sleeping on this, I think that the difference between the installations that work and those that don't is the timezone of the server. All my installations are on servers set to -5 or -6 hours and they all work. All your installations are set to +1 hour and they all fail. My suspicion now is that there is some place in the code where the server timezone adjustment is adding 1 hour to the timestamp that is supposed to mark the end of the week, which would move it to the following week. If that is happening in some calculations but not in others, we would end up with the confusion we are seeing with double weeks and wrong week labels.
I'm going to dig through the code for any places where the server timezone might not have gotten removed properly.
#22
In digging into this, I found several places that were possible culprits for accidental injection of a timezone adjustment by the server, so I did a re-write to fix that. The good news is that while I was making the changes I eventually got to the point where my system was displaying duplicate weeks in the same way that Chris's was, which makes me hopeful that now that it is working right on my system it will also work right on his. The fixes have been committed to HEAD only, and require a new function I just added to Date API, so you'll need the latest code for date.inc as well. Chris, can you see if the latest code makes your problems go away?
I needed some of the custom date functions in Date API to do it, so I also replaced all php date functions with the wrapper functions used by Date API, which means that the Calendar can now display historical dates as well as current dates if the adodb library is being used by Date API. So a nice extra feature that has come out of all this work is support for historical calendars.
#23
Sure - but am just heading to bed (early start tomorrow). I'll grab the files tomorrow at work. I guess that means that the nightly HEAD release for each will be OK? If not I can grab the CVS HEAD itself :)
#24
Well - I have just run the following:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib co -d calendar contributions/modules/calendar
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib co -d date contributions/modules/date
Then I ran update.php. So a TRUNCATE cache; in the database and finally an open the calendar view and save it.
Calendar is giving:
Fatal error: Call to undefined function date_time() in /srv/www/www.chrissearle.net/htdocs/modules/calendar/calendar_api.inc on line 344Executed 24 queries in 4.59 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted.
ms # where query
0.11 1 drupal_lookup_path SELECT COUNT(pid) FROM url_alias
0.2 1 module_list SELECT name, filename, throttle, bootstrap FROM system WHERE type = 'module' AND status = 1 ORDER BY weight ASC, filename ASC
0.14 1 locale_supported_languages SELECT locale, name, formula, enabled FROM locales_meta ORDER BY isdefault DESC, enabled DESC, name ASC
0.34 1 user_load SELECT * FROM users u WHERE uid = 1
0.06 1 user_load SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 1
0.07 1 profile_load_profile SELECT f.name, f.type, v.value FROM profile_fields f INNER JOIN profile_values v ON f.fid = v.fid WHERE uid = 1
0.07 1 og_get_subscriptions SELECT n.title, n.type, n.status, ou.* FROM og_uid ou INNER JOIN node n ON ou.nid = n.nid WHERE ou.uid = 1 AND ou.is_active >= 1 ORDER BY n.title
0.06 1 og_user SELECT og_email FROM og_uid_global WHERE uid = 1
0.92 1 cache_get SELECT data, created, headers, expire FROM cache_menu WHERE cid = '1:en'
0.12 1 calendar_views SELECT vid FROM view_view ORDER BY name
0.19 1 _views_load_view SELECT v.* FROM view_view v WHERE v.vid = 5
0.07 1 _views_load_view SELECT * FROM view_sort vs WHERE vid = 5 ORDER BY position ASC
0.07 1 _views_load_view SELECT * FROM view_argument WHERE vid = 5 ORDER BY position ASC
0.07 1 _views_load_view SELECT * FROM view_tablefield WHERE vid = 5 ORDER BY position ASC
0.07 1 _views_load_view SELECT * FROM view_filter WHERE vid = 5 ORDER BY position ASC
0.29 1 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'views_tables:en'
0.14 1 _views_load_view SELECT * FROM view_exposed_filter WHERE vid = 5 ORDER BY position ASC
0.07 1 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'views_with_inline_args:en'
0.11 1 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'views_style_plugins:en'
0.18 1 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'content_type_info'
0.41 1 date_views_browser_get_views SELECT arg.*, view.name FROM view_argument arg INNER JOIN view_view view ON arg.vid=view.vid WHERE arg.type IN ('') AND view.page_type='date_views_browser'
0.39 1 sess_write SELECT sid FROM sessions WHERE sid = 'a853ca3143aeae0a49fed33a5b51f358'
0.31 1 sess_write UPDATE sessions SET uid = 1, cache = 0, hostname = '192.168.3.140', session = 'update_total|i:0;og_last|N;', timestamp = 1173967032 WHERE sid = 'a853ca3143aeae0a49fed33a5b51f358'
0.16 1 sess_write UPDATE users SET access = 1173967032 WHERE uid = 1
0.09 0 list_themes SELECT * FROM system WHERE type = 'theme'
So - is the date.inc file not in the date module? Or did I misunderstand?
#25
Yes, date_time() should be set up in date.inc, which should be in the date module. And it should be included on line 344 by calendar_load_date_api(); a couple lines above it, so I can't understand why you're getting a message that the function does not exist.
Can you confirm that the function exists in your copy of date.inc (line 233)?
I'm not getting any error, can't figure out why you are...
#26
Never mind, I figured it out. I updated the 5x version of the date module instead of the HEAD version, so the HEAD version is indeed missing that function. Fixing that now...
#27
OK - now I am totally confused. I did a cvs up and got a new date.inc. I see the date_time function - but - even after an update.php, an edit/save of the view and an emptying of the cache the error of not finding the function continues. Now - is there any way I can find out from drupal which date module (path on disk) it is loading ? I am wondering if it is getting the sites/all/modules/date instead of the sites/www.chrissearle.net/modules/date (although its loading the sites/www.chrissearle.net/modules/calendar instead of the sites/all/modules/calendar just fine)
#28
If you go into your database and look at the system table, find the date module and you can see what path it is using.
#29
Actually I should say, find the date_api module and see what path it is using.
#30
OK.
select filename from system where name in ("date_api", "calendar", "date");
sites/all/modules/date/date.module
sites/all/modules/date/date_api.module
sites/www.chrissearle.net/modules/calendar/calendar.module
Theres the reason. I manually change the db to fix. I now see:
sites/www.chrissearle.net/modules/date/date.module
sites/www.chrissearle.net/modules/date/date_api.module
sites/www.chrissearle.net/modules/calendar/calendar.module
And I get:
Fatal error: Cannot redeclare date_time() (previously declared in /srv/www/www.chrissearle.net/htdocs/modules/date/date.inc:233) in /srv/www/www.chrissearle.net/htdocs/modules/date/date.inc on line 265
So - I dig further:
/**
* Implementation of time() adjusted for the current site and user.
*
* @param $offset - optional method to force time to a specific offset
* @return integer timestamp
*/
function date_time($offset = NULL) {
global $user;
if ($offset) {
return (time() - date("Z")) + offset;
}
elseif (variable_get('configurable_timezones', 1) && $user->uid && strlen($user->timezone)) {
return (time() - date("Z")) + $user->timezone;
}
else {
return (time() - date("Z")) + variable_get('date_default_timezone', 0);
}
}
/**
* Implementation of time() adjusted for the current site and user.
*
* @param $offset - optional method to force time to a specific offset
* @return integer timestamp
*/
function date_time($offset = NULL) {
global $user;
if ($offset) {
return (time() - date("Z")) + offset;
}
elseif (variable_get('configurable_timezones', 1) && $user->uid && strlen($user->timezone)) {
return (time() - date("Z")) + $user->timezone;
}
else {
return (time() - date("Z")) + variable_get('date_default_timezone', 0);
}
}
So - I delete the duplicate function (basically - a long winded way of saying - is the CVS head correct?)
then a save of the view, a truncate of the cache table and then http://www.chrissearle.net/calendar has the weeks
10, 11, 12, 13, 13
:(
#31
Yes, date.inc was right in the first place, I didn't need to add anything to it, so I just committed a fix to reverse that.
Still wrong, huh? Wow, I was sure I found it this time. Well, I'm going to go ahead and commit these changes to all branches because they include a number of small fixes I found as I was digging through the code (and added the ability to display historical calendars).
I guess I'm just going to sleep on this one for now. I have no more ideas of what to try.
#32
Another variation of this was reported at http://drupal.org/node/130058, which I've marked as a duplicate.
#33
Since I've never been able to get the week view working completely right in all situations (and I never have been able to replicate this problem on my own installation so I could debug it), I'm hiding the week view in the calendar completely for now, and I'll just have to get back to this later.
#34
Hi,
I'm not sure, if it's a separate bug, or actually a part of a 'week story', so I report it here.
When I have a day view open (say: May 17th), and click on "Week view" (the link says .../2007/W20 - which seems to be correct as itself), a page opens with a week signed '20', but in fact containing a week 19 (commencing Monday, May 7th). When browsing previous months, I noticed that week numbers were screwed up in general: January started with week 2 and the latest days of a month were reported as a disparate week, than the first days of the following month.
Versions:
Drupal 5.1.
All modules are official releases versions: calendar-5.x-1.4, date-5.x-1.5.
Configuration:
First day: Monday
Time Zone: GMT+2
Configurable time zones: disabled
Best regards,
Jan.
#35
This should be fixed in the 5.2 version, which is not quite ready for an official release. You can see that release if you look for 'other releases' on the project page. Try it in a test environment, or be prepared to update it as bugs are found and fixed.
#36
Automatically closed -- issue fixed for two weeks with no activity.
#37
In case someone else comes across this thread... I did the same thing but got weird results... I used this instead:
.week {
display:none;
}