When I enter "now" for the filter in the views admin interface, I still get an error saying "Date is invalid." If I expose the filter, and enter "now" on the view page, it works. I've tried clearing the cache, clearing the view cache, editing and resaving the cck type, but the bug seems to really be there.

Here's my version info:
- php 4.4.4
- drupal 6.2
- views 6.x-2.0-rc1
- date 6.x-2.x-dev, tarball with this changelog: v 1.1.8.86 2008/07/25 14:40:45

(This is a similar issue to #277420: Date filter in views not functioning properly, but for d6.)

Let me know if you want me to export my field or view.

Comments

Stoke’s picture

Same here :/

wundo’s picture

Component: PHP4 Module » Date API
Assigned: Unassigned » wundo

Same here.
But with php 5.1.2, looking deep into Date code it´s not PHP/Drupal related, the bug is within Date's code

KarenS’s picture

Status: Active » Fixed

PHP 5.1 uses the same wrapper code that PHP4 uses. Only PHP 5.2+ uses native date handling.

If you have looked deep into Date's code far enough to be think it is a Date bug, it would help if you provide more information instead of just pronouncing that this has nothing to do with PHP.

However if you are trying to put 'now' into the Date field it will not work, you have to put 'now' into the adjustment field. If it works outside the administrative interface, that's not because it's right, it's because the validation is only working in the interface and the code is still evolving. I am trying to get to the point where we can use date widgets in the filter and they can't accept 'now' as a date so 'now' has to go in the adjustment field. I've explained this in several other issues already.

wundo’s picture

I'm appointing Date module as the cause, because in line 672 (from //$Id: date_api.views.inc,v 1.1.4.23 2008/07/23 19:28:02 karens Exp $) we have

if ($part != 'adjustment' && $granularity != $handler->arg_granularity($value)) {

and arg_granularity returns '' when we pass 'now' as argument.
Anyway, checking granularity for 'now' sort of lack of sense for me, but I'm no date expert, I'm just an user trying to help. But my test shows that changing to

      if ($value != 'now' && $part != 'adjustment' && $granularity != $handler->arg_granularity($value)) {

fixes this bug for me.

Obviusly it doesn't seems as a proper solution, but it indicates me that it's not PHP 5.2.1 related. (arg_granularity('now') failing maybe PHP 5.2.1 related, but I don't understand why we should check the granularity from 'now'. Maybe I'm missing the point.).

-beta3 didn't suffer from this problem, and sorry if I missed all those issues where you already said about this issue.
I just followed your advice in #261818 to use -dev and then just followed the help text from the interface and tried to put now as date.

Again, I'm a module maintainer also, and I understand you are working hard to get everything working. I'm just trying to help, you don't need to be harsh.

sprugman’s picture

I don't have an adjustment field. I only have a Date field. I'm trying to put "now" in the box right above where it tells me in the help text to use "now".

Here's a screenshot: http://bowlerhat.us/xfer/views-date.png

wundo’s picture

Status: Fixed » Active

PS: as it seems it´s not fixed, re-opening the issue

KarenS’s picture

#5 There is a settings form for the filter (it looks like a gear, next to the filter name). You have to select that to change filter options like whether or not there is an adjustment field.

#6 Can you be more clear about what is not fixed? If it is that you don't see an adjustment field, see #5.

sprugman’s picture

Ah-haaah! Thank you. I looked through that other thread, but I guess I didn't read it carefully enough. (It's kinda long....)

In any case, I would say that you still have a bug, but it's a usability bug, not a code bug. I had ignored the "Adjustment" choice because I thought it had something to do with time zones. Obviously, I should have read the fine print more closely, but even if I had, I'm pretty sure that "the date can be a specific date, or 'now'" would have lead me to do the wrong thing. Here are a few suggestions for improvement (hopefully):

Configure extra settings for filter "Date: Date"

I would think about changing the names of the modes, since with "now", don't feel like I'm making an adjustment. Maybe change the choices to something like:

  • Relative to "Now"
  • Specific Date
  • Specific Date with Adjustment

and the help text to something like:

  • Relative to "Now" - Filter relative to the user's current time, using either "now", or an adjustment like "+1 day". (Plus maybe a link to strtotime() to see what other kinds of adjustments are available. Or probably that link goes on the help text in the other panel.)
  • Specific Date - Filter relative to a specific date, such as "July 17, 2008".
  • Specific Date with Adjustment - Filter relative to an adjusted date, e.g. July 17, 2008, +1 day.

Come to think of it, what's the use case for the Date with Adjustment mode? If I want July 17th, "+1 day", why wouldn't I just enter July 18th in Date Only mode? I'm sure you have one, I just can't think of it. :-) Maybe something to do with exposed filters?


Configure filter "Date: Date"

Even if you don't change the mode names, the help text on the config panel could use some clarification. If I've chosen Date Only, this text:

Date format YYYY-MM-DD. Leave date blank to do no filtering, use 'now' to filter for the current date.

really needs to tell me that I have to be in one of the "adjustment modes". Maybe something like:

Date format YYYY-MM-DD. Leave date blank to do no filtering.

To filter for the current date, change the Filter Type to "Adjustment only" and enter "now" in the Adjustment field.

The Date Plus Adjustment mode help text is misleading, too. It makes me think I need to put "now" in the date field and "+1 day" in the adjustment to get that kind of behavior.

I would also add the "now" instruction to the Adjustment mode instruction, which currently just says:

'Adjustment' filters for an offset like '+1 day' from the current time.

That language almost makes me think I could leave it blank for "now" behavior. I'd just add: "Use 'now' to filter relative to the time at page load." (Or something like that.)

KarenS’s picture

Yeah, I am not happy with the filters yet -- they have elements of the previous filter handling and elements of the way that Views2 does core date fields so it's confusing and probably not right. I want to get to the point where the 'date' part is a regular date widget instead of a textfield, so then I have to figure out what to do with the adjustment. People like and expect to be able to use 'now' so adding that in is just for backwards compatibility because you're right it doesn't really change anything. '+1 day' is exactly the same as 'now +1 day'.

I'm open to suggestions, I'll look at your ideas when I get back to working on the filters.

KarenS’s picture

Status: Active » Needs review

I did a rework of date filter to provide a choice of a widget to use for the filter form and an option to set the default value to a set date or something like 'now +90 days'. Setting a default value is really what that 'adjustment' field was always intended to do, but it was confusing.

This is where I was originally going to take this filter, but I was having trouble getting it to work until now.

I think this is much more intuitive and useful, and it provides a way to use different date widgets for selecting the date. At the moment, only a date_select widget is available since I want to focus on getting the basic functionality working before adding in the complexity of using other widgets.

You must delete any previously-created date filters and re-create them to pick up the new parameters.

I've tested this in both PHP4 and PHP5 and it appears to be working correctly (I did find a couple other PHP4 fixes that were needed and those are in the latest code, too.)

I'm marking this 'code need review' just to indicate I'd like other people to try this out and see what kinds of problems there are.

If it seems to be working well, that was the last major change I wanted to get in before creating a new release of this code.

sprugman’s picture

I'll check it out once the tarball comes down....

KarenS’s picture

Status: Needs review » Needs work

Hmm... well it starts with the right default value in the exposed widget, and the default value properly takes into account the relative values, but there's some oddities in the initial query that is created before you submit the form. The query rights itself as soon as you submit the form, but the initial query is not right. I'm investigating this...

KarenS’s picture

Status: Needs work » Fixed

OK, now it's fixed and working correctly.

daniel-san’s picture

This solved the filter on "=>now" issue I was having as well. Works on my block view of upcoming workshops. Using current dev version, past events do not show in the list. Woo hoo. Awesome work Karen. Thanks so much.

sprugman’s picture

it's working for me, too. thanks!!

Anonymous’s picture

Status: Fixed » Closed (fixed)

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