I am using the latest and greatest -dev's, I have set up my sites date/timezones properly (I believe).

When I am on the Month view I see the correct month, but when I click Week (just tried this today, August 18th), I get a URL like /week/2011-W32 and see "Week of July 31 2011". If I click Day, I see "Sunday, July 31 2011"

Today is August 18th.

Did I mess up some little dumb setting somewhere? Any help is appreciated.

Comments

Category:support» bug

I'm having this same issue. Today is the 20th and when I click "Week", it goes to Week 32 (July 31st). When I click "Day," it goes to August 1st!

I realize this may not be a Calendar bug, it may be a Views bug. Going to /week or /day knows what the correct week and day are, but it's incorrect when using the *pager* links at the top.

@ #2, same for me. If you go to the URL /calendar/weeek or /calendar/day provided by the default view, it works, but the pager itself appears to be broken. Is there a pager setting somewhere in the GUI that I missed configuring?

Replicated and subscribing.

Same for me, I think it is a granularity issue, as soon as you go from a less focus granularity to a more focused one (like from week to day) it goes out of sync. So if you go to week display, for example, it starts the week on the first day of the week, a Sunday. So while today is September 2, a Friday, you've altered the search to start on the first day of that week. So when you go to day view, you are now looking at the 28th, not today's date. And it seems to remember the last date it was on the last time you clicked on that display.

Interestingly, if you make the links from a menu yourself and use the vanilla paths (/calendar/week, calendar/day) instead of the links the module wants with one more level after them (/calendar/month/2011-08) it works properly. So until it is fixed, maybe you can disable the code that displays the other displays and use your own tabs to display whatever views you want. Karen is working on this section of code and creating new tabs instead of the ugly text links, so maybe she will get all that working soon.

I also have this issue! In month view everything is okay, in week and day views the issue appears.

#4 - how do I remove the pager at the top? I agree, I'd like to replace them anyhow.

Well, since I don't need these links, I turned them off by commenting out where the calendar links are added to the page. In calendar/theme/theme.inc, line 63, just comment out $vars['pager_prefix'].

Note, this is in the dev module as of August 20, NOT the most recent one, since that sounds like it has even more problems......

same problem here
Any patch to fix it?

same here and subscribing..

+1

Bump

Subscribing

Subscribing

Subscribing

Priority:Normal» Major

I managed to locate the issue.

When supplying a date argument, the $view->date_info of the calendar has four properties to base the tab links on (day, week, month, year) that seem to fall back on the first item of that view.

Example:
The month view of September 2011 has:

  • day 1
  • week 35 (29 Aug)
  • month 9 (duh)
  • year 2011

This is all dandy, up until the point where you expect it to go to the current month, week, day, etc..
The problem lies with the fact that even when you don't supply a date argument in the URI, Drupal still supplies one behind the scenes.

So what Calendar should do is check the URI for date arguments. If none are present, it should figure out you want to view the current day, week, month or year with the tabs and thus not add any date arguments to their links.

Instead, it thinks your viewing just any random year, month, week or day and supplies links to the first 'item' of each type. Just like the September example.

Updated status to major since no author has replied in a long time.

Another example:

Navigating to /calendar/month correctly displays the current month (October).

However, the Month, Week, Day, Year links look like this:

<ul class="tabs primary">
  <li class="active"><a href="/calendar/month/2011-10">Month</a></li>
  <li><a href="/calendar/week/2011-W39">Week</a></li>
  <li><a href="/calendar/day/2011-10-01">Day</a></li>
  <li><a href="/calendar/year/2011">Year</a></li>
</ul>

So Month links correctly, Week links to W39 (this is week 43) and Day links to 1st October (this is 26th October). Year links correctly to 2011.

I've done a little more digging on this and I think the problem is tied to the date_pager_url() function called in theme.inc and from the date_views module which is part of date api. Whether the function is at fault or we're passing it bad data, I don't know.

<?php
   
if ($display->display_options['style_plugin'] == 'calendar_style' && !empty($display->display_options['path'])) {
     
$path = $display->display_options['path'];
     
$title = $display->display_title;
     
$type = !empty($display->display_options['style_options']['calendar_type']) ? $display->display_options['style_options']['calendar_type'] : 'month';
     
// Make sure the links to other calendar displays use the right path for that display.
      // Get rid of pager links when swapping between displays to force the base argument
      // to be structured correctly for the type of display. This means you can't use
      // these links in a block or panel.
     
$href = str_replace($current_path, $path, date_pager_url($view, $type, NULL, TRUE, FALSE));
     
$part_path = substr($href,strlen(base_path()));
     
// Once we have a path for the links to other displays, add it to our links array.
     
$calendar_links[$current_path]['tabs'][$type] = array('title' => $title, 'path' => $part_path);
     
$calendar_links[$current_path]['types'][] = $type;
    }
?>

More about date_pager_url() http://api.lullabot.com/date_pager_url/7

[Edit: This was a red herring. But a step along the way of working out what was happening.]

I think current behaviour is correct if there is a valid date argument (contextual filter) present in the URL - perhaps apart from /year/YYYY which seems inconsistent.

  Month link to Week links to Day links to Year links to
month/YYYY-MM MM week in which 1st of MM occurs 1st of MM YYYY
week/YYYY-WXX Correct month WXX 1st dat of week XX YYYY
day/YYYY-MM-DD YYYY-MM Correct week YYYY-MM-DD YYYY
year/YYYY YYYY-12 Last of year YYYY-MM-01 YYYY

However, the behaviour when no contextual filter is present in the URL is odder. Views provides a default contextual filter of the current date, which it does correctly. Then the links work as above.

However if no contextual filter was present, it seems more logical for these links to be without contextual filters also. So on a page /month, the links should just be to /month, /week, /day and /year

Any thoughts?

[edit: the same conclusion that @kristiaanvandeneynde came to above]

Component:Miscellaneous» Code
Status:Active» Needs review
StatusFileSize
new882 bytes

A patch that checks whether views supplied a default argument (i.e. there wasn't one in the URL) and removes the date element from the month, week, day and year links if that's so. It leaves links alone if a date argument was already in the URL

This does not change the behaviour of the calendar if there is a date argument present in the URL.

Will test and review this patch as soon as I'm back in the office.
Currently on vacation :)

Priority:Major» Critical
Status:Needs review» Reviewed & tested by the community

Tested, seems to work perfectly for me.
Updated to critical seeing as maintainer still hasn't replied yet.

Same problem. Once in year view, day month and week links do not go to day, moth, week for current date.

I have exactly the same problema. Links of month and day in year view go to December of that year.

Just to reiterate: until the patch supplied above by @mshepherd is committed, you can apply it yourself to fix the problem.

patch @ #19 works for me +1

Status:Reviewed & tested by the community» Needs work

That patch will not work at all correctly if you try to use the back/next navigation. You end up with links back to the current date no matter where you go in the calendar. So if you navigate forward several months, into the next year, then click on a link, it will take you back to today in the new view.

The intention of these links is that they will keep track of where you are and take you to the appropriate place in the new view. They do this by populating the links on the first page, then replace the values that need to be replaced based on where you have moved in the calendar.

With the patch above, the replace does nothing because the values are missing, so the links are always the same: month, year, day, week, with no dates.

There obviously is some problem in the logic, but this isn't the right way to fix it. Unless we want to give up on having the calendar keep track of where you are and always snap you back to 'today' when you switch between year, month, week, and day. Google calendar keeps track of where you are, and that's what I'm trying to model this after.

Actually, the patch works if you are using the 'clean' option for the pager links, but not if you use the 'pager' option, so it still isn't a fix.

How do you tell if it's set up to use the 'clean' or 'pager' options for the pager links? If this will work for me, I'd like to try applying the patch...but i'm on windows, so it's difficult to apply a patch (if anyone knows an easier way, PLEASE let me know) but I'd like to make sure the patch will work for me before I go through everything to apply it...

Thanks!

Ok 6 or 7 months now on this issue. What is the status of the calendar working properly? Karen, I know you are busy, can you let us know the plans for working on this module? With all due respect for your hard work, it took 4 or 5 months for you to reply here about this issue (December 20) and it has been almost a month and a half again with no word from you. If we just knew what was going on (or not) with development, that would be great.

I didn't have anything to respond to, I said the patch wouldn't work and was hoping someone would figure out why. Since no one did, you had to wait until I had time to get back to this.

I decided the first step was to figure out why $argument->is_default wasn't reliable when used with a pager format and just made a commit to Date to make it work consistently for all formats:

http://drupalcode.org/project/date.git/commit/4aa1144

I'm not sure the rest of the patch is what we want anyway, but I think that was a good change to make.

The links are attempting to keep track of where you are as you click around and provide links to relevant locations on the other views based on that. This is the way that Google Calendar works -- you don't go back to 'today' if you click around in the month view and then switch to a week view, you see a week that is a part of the month you're looking at. This works fairly well when you move to views that are bigger (from a day to a week) and doesn't work right if you move to views that are more narrow (from a year to a month). The original logic was to keep track of the current day as the first day of whatever view you were looking at, but that clearly isn't working well enough. So I have to see if there's a way to make it smarter and I guess if I can't it will just have to go back to 'today' every time you switch a view.

Status:Needs work» Fixed

I decided to just give up on trying to do this intelligently and went back to everything just goes back to 'today' when you switch from one view to another.

http://drupalcode.org/project/calendar.git/commit/1bc60b3

Karen - THANKS!!! cb

I'm sorry, I don't quite understand commits. How do we use the two above commits to fix this, at least to go to the 'today' setting, like Karen says in #31...?

Please please explain, thank you!

girlwithquestions: the commit is just a piece of information showing what was changed in the code base stored at drupal.org.
To get the latest version of code, just download the -dev version from the project page.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:7.x-3.x-dev» 6.x-2.x-dev
Priority:Critical» Major
Status:Closed (fixed)» Active

Hi there, I just experienced similar problems with a live D6 site. Have a calendar week view and the top link for next week in 2012-W52 points to 2012-W1 instead of 2013.. (exactly like http://drupal.org/node/1407020#comment-5519776 which was directed to this thread).

Cannot seem to fix it and installed latest devs (date + calendar), any ideas

I experienced the same as described in #36.