Document DateTime usage & debugging techniques

I have same problem with the date filter using Date 6.x-2.0-dev (2008-Nov-22). It seems to work if using 'greater than' but not otherwise.

Hi, exactly ame problem ^^.

Same problem using "less than" or "less than or equal to"

down graded to RC4 and view works again.
Appears to be an issue with the new multiple field Boolean.

Live example at http://dev.cornellclubdc.org/archive ; if you filter for nodes where the date is greater than 2009-01-01 there is no problem, but if you try to filter where the date is less than 2010-01-01 the results are blank; those same nodes fail to appear. This is a newly created view on a 6.6 site, cache purged, using 21 22 Nov dev of date, 19 Nov dev of views, and cck 6-2.1.

Also reported in the Views issues queue at http://drupal.org/node/337595 .

same problem - getting no results where is should for:
'is less than' 'now'
'is less than or equal to' 'now'
tried the 'and' and 'or' methods

if i use between 'now -20 years' and 'now' i get a number of results

I just committed some fixes that should take care of this. The date filter was getting the view date wrong in some situations.

I have the same problem with Drupal 5.1. I upgraded to the new Date module, as well as CCK and Views (and Tokens, etc., per the instructions). The result is that the date filters in views do not work anymore. Dates passed by argument are fine, though.

Don't change versions. The code in the D5 version is totally different than the code in the D6 version, so the problems and the fixes are different and can't be mixed together. The D5 version uses Views 1 and the D6 version uses Views 2, and there is absolutely nothing about those two versions of Views that works the same.

I fixed the D6 version. I haven't done anything with the D5 version. If there's a problem in D5, it needs its own issue (and I think there already is one).

Excuse me -- didn't realize it would change the version for the whole thread!

BTW, it seems interesting that given the complete difference in the code base of the two views modules, that a similar problem occurs.

Still not working for me after installing the dev-Nov25th version.

More details (unless the above issue is somehow different):

I have a view that selects past events, so the filter is for a CCK Date field that is less than "now". With rc5, it was using 0001-01-01 in the SQL as "now". With the latest dev, it uses 2005-01-01 for "now". Actually, if I use the "less than" option, it doesn't matter what I select for the date -- absolute value or relative value.

I worked around this with a suggestion from post #7 -- using "is between" from "now-2 years" to "now" produces the right SQL. The "is greater than" option doesn't seem to affected by the same bug.

Still have same problem after updating to lates (today) devs of Date, Event, Calendar and trying the mods at #14. That did produce a list of nodes but not the right ones.

Do you know if this bug could be realted to http://drupal.org/node/339532 ?

It looks like it. But the latest post from that Views issue seems to say that it should be referred back to the modules supplying the data to Views.

If your problem deals exclusively with fields or filters provided by another module .............. please post the issue under the queue for that module first; all modules are responsible for telling Views about their own fields. It's possible Views IS at fault, but the module maintainers are the best people to make that determination, and they can kick the issue into the Views queue with an explanation of what's wrong if that is the case.

In my case that looks like either Calendar or Date. So I'm hoping for good results from http://drupal.org/node/339532.

I can confirm the same bug as reported in comment 14 including 2005-01-01 in DRUPAL-6--2 and 0001-01-01 in DRUPAL-6--2-0-RC5. Similarly > and >= work, while < and <= do not.

I think 2005 comes from the default +3:-3 year-range setting and maybe related to this recent addition to 2.x in includes/date_api_filter_handle.inc to date_api_filter_handler::init();

  // Set the view range, do this only if not already set in case there are multiple date arguments.
  if (empty($this->view->date_info->min_allowed_year)) {
    $range = $this->year_range();
    $this->view->date_info->min_allowed_year = !empty($range) && is_array($range) ? $range[0] : variable_get('min_allowed_year', 100);
    $this->view->date_info->max_allowed_year = !empty($range) && is_array($range) ? $range[1] : variable_get('max_allowed_year', 4000);
  }

The WHERE clause of the query;

  WHERE (node.type in ('course'))
      AND (DATE_FORMAT(STR_TO_DATE(node_data_field_deadline.field_deadline_value, '%Y-%m-%dT%T'), '%Y-%m-%d') < '2005-01-01')

I started debugging this but was unable to see any properties of the DateTime object in my IDE (Komodo) or with print_r() in date_api_filter_handler::date_filter();

  $min_date = $range[0];
  $max_date = $range[1];

If someone can let me know how to debug DateTime objects or where the class is defined (I couldn't find it anywhere in date API or PHP documentation) I can keep debugging this.

For now I am working around this by using a 'between' operator with "now -100 years" and "now" values. I had to set the method to AND to get that to work.

Yes this was broken when the new year range limit was added. This is fixed in -dev and the fix will be in the next release.

FYI, I tried installing the build from November 29 and it still has this bug in my case.

I just fixed it today, so the build from yesterday obviously does not have the fix.

cool!

Thanks Karen! You rock!

Btw, how can I debug DateTime objects and where can I find documentation on them? What's this black magic you're using?

You can't tell anything by looking at it. I use something like the following to see what those date objects hold:

print date_format($date, 'l r');

The 'l r' format will give you the day of the week, the date and time, and the timezone offset. Or you can add 'e' to see the actual timezone name the object is using.

I need to write up some info on how this stuff works, but a couple real simple examples:

// Create a date object for Nov 11, 5pm, Chicago time.
$date = date_create('2008-11-11 17:00:00', timezone_open('America/Chicago'));

// Find out what time it is in New York.
date_timezone_set($date, timezone_open('America/New_York'));

// Now move it ahead to the following Tuesday.
date_modify($date, '+1 Tuesday');

// Print out the result.
print date_format($date, 'l r'));

I should add, 90% of the time I just use the four functions in the example above to do practically anything I need to do with dates. There are some other date functions, but I rarely use them.

I found some pretty poor documentation for this at http://nz.php.net/datetime. I wonder where best to document your debug code snippets in #24 and link to PHP.net's documentation? Date's README.txt? I think at the very least some of this info should show up when a developer does grep -r DateTime date. What do you think?

Yes, the documentation on php.net is quite poor. I'm actually getting rid of a lot of the README.txt files in favor of links to documentation pages on d.o and internal Advanced Help pages because the README.txt is too limited to be of much use and it quickly gets out of date (and I tend to forget to update it).

I'm becoming a fan of Advanced Help and am starting to move my documentation there. Basically it's just a bunch of html pages that can use full html, including images for illustrations, and has ways to link to other Advanced help pages and structure the pages in sections. I've got the very beginnings of some documentation about the API, but it needs lots of work, and I'm *always* open to patches if anyone wants to help :)

I never use the term 'DateTime' anywhere, so no one would find that anyway, but I agree it would be good to get things documented better.

A new file for help/ attached. I haven't worked with advanced help before or even used it extensively, so I'm not sure if this needs to be registered anywhere or if it's existence is sufficient?

This is fine, I can put regular html files into the help folder in Date and I just need to add a marker in the help .ini file to tell Advanced Help that it's there.

Could you strip out the "span style="color: rgb(255, 128, 0);" stuff though? Thanks!

That adds syntax highlighting, which I think is rather useful. Try previewing the file in a browser – don't you agree that it's useful?

Sorry! I didn't look at it in a browser, I assumed it was accidentally left in there by some dumb word processor :)

Is this RTBC then?

dsm(): legacy function that was poorly named. use dpm() instead, since the 'p' maps to 'print_r'.

OK, I'm committing this, with the change mentioned in #33. I'm also moving the original README.txt into Advanced help and will remove that.

Nice! Thanks all! :)