NOW problems again.

Same problem here again. The previous 6.x-2.x-dev (2009-Mar-03) fixed the issue, and we used it so far. Now 6.x-2.1 is creating the same issue. When I tried to delete the filter and to add it again in Views, I was given the following 3 (same) filers oddly:

Date: Date
Filter any Views date field.
Date: Date
Filter any Views date field.
Date: Date
Filter any Views date field.

Any idea?

Same here again.

In my case it gives two options for the date filter, i tried both, but they do the same: nothing.

Datum: Datum
Filter any Views date field.
Datum: Datum
Filter any Views date field.

It don't even add a date filter to the query:

SELECT node.nid AS nid,
   node_data_field_date.field_date_value AS node_data_field_date_field_date_value,
   node.type AS node_type,
   node.vid AS node_vid
 FROM node node 
 LEFT JOIN content_type_dienst node_data_field_date ON node.vid = node_data_field_date.vid
 WHERE (node.type in ('dienst')) AND (node.status <> 0 OR node.uid = ***CURRENT_USER*** or ***ADMINISTER_NODES*** = 1)
   ORDER BY node_data_field_date_field_date_value ASC

I can confirm that no filter is applyed in the query.
I'm using a ">=now" filter in my view, but in the SQL there's nothing related to date.

Same problems as #2. An earlier dev on a test site did fix this "now" selection problem.

hmm, sorry to say but same problem here...

3 same filters in Views (like #2) and not working 'now' token.

Exact same problem here. The data restriction disappeared from the generated SQL query.

I've run this through the debugger. It's knotty.

The call to date_api_filter_handler::date_filter() isn't checking for the following:

Relative value

Relative values will be used if no date is set above. Use 'now' to default to the current date at runtime or add modifiers like 'now +1 day'. The To date default value is used when the operator is set to 'between' or 'not between'.

If the filter is exposed, these values will be used to set the inital value of the exposed filter. Leave both date and default values blank to start with no value in the exposed filter.

The reason that the date clause of the query disappears is that if 'max' and 'min' are null in calls to date_filter(), it craps out. If you're specifying a relative time, as suggested above, your "values" are actual in 'default_date' and 'default_to_date'.

But even if this is fixed, I think you're still screwed, since I've just noticed that even if you use the 'max' and 'min' fields, date_filter is doing the time zone conversion backwards (it's converting the date widget's time from local time backwards):

DATE_FORMAT(CONVERT_TZ(FROM_UNIXTIME(node_data_field_event_start.field_event_start_value), 'UTC', 'America/Los_Angeles'), '%Y-%m-%d') <= '2009-03-26'))

The mistake here is that FROM_UNIX time is going to covert the Unix time stamp into local time (mine's America/Los_Angeles), so in effect, it's doing the time zone conversion twice.

Unless MySQL (or your favorite server) is set to UTC as its time zone, this code is wrong.

Here's a "fake patch" to show how to get around what's clobbering the relative default dates. It's test code, and since I haven't played much with Views 2, it probably isn't generally valid either.

But again, date_filter isn't handling max and min arguments either in 6.x-2.1 anyway.

Sigh! I have fixed several things this morning:

1) The three filters -- that is because we have added in the capability to use the Users and Comments tables as base tables for dates. If you create a new view with a base table of Users or Comments, you will see only the one filter that applies, but for some reason if you have a base table of 'Node' you get all the filters. That is probably a Views bug or maybe by design for some reason I don't understand. Anyway, I added descriptions to the filters to make it more clear which is which. You also get all fields in the fields list for the 'Node' option, but again that is what Views provides so I'm using it.

2) I made a fix for exposed filters just before this release that inadvertently broke non-exposed filters. That should be fixed now.

With those fixes I'm pretty sure this patch is totally unnecessary, but I'm going to do some testing of the 'between' options to be sure.

Also re #8

The mistake here is that FROM_UNIX time is going to covert the Unix time stamp into local time (mine's America/Los_Angeles), so in effect, it's doing the time zone conversion twice.

Unless MySQL (or your favorite server) is set to UTC as its time zone, this code is wrong.

We *DO* set the server to UTC before all computations using @@session. Views already does this in many places and Date tries to add it in where it isn't already. You should always see a @@session query setting the server timezone before any Date query. We do that because the server timezone is an unknown quantity and may or may not be set to the timezone we really want (there is no guarantee the server timezone matches the site timezone, let alone the date or user timezone), so we always set it to UTC so we know exactly what we're working with.

BTW, the 'Sigh!' was not me being upset with anyone reporting problems, it's me being upset with myself that there are still problems in the release.

I don't see any remaining problems with the between filters after this morning's fixes.

same problem on my site. am using mar 26 dev version. sql in views seems not be filtering by date at all. Am trying to do event listing so date> now

With the March 26 dev version, I get the same issue, where the query is not being filtered for any relative dates. Absolute date is definitely working fine. Like the person in #1 said, there is NO date filtering in the query.

Further examination shows that it works fine with an exposed filter, but not hidden. A hidden date filter simply does not end up in sql query.

For now I have exposed the filter and hidden it using css, so I get the functionality I want on the pages. Having said that exposed filters don't work in blocks so there is still a problem there.

Thanks Karen, with your new dev version my condition (#4) is fixed!

Confirming that the DEV snapshot of Mar 26, 2009 fixes this problem in my situation.

I can confirm I'm seeing the exact same behavior in the March 25th release. Haven't upgraded to dev yet.

For the people reporting about problems with 'March 26 dev version', it totally depends on where you got that version from so you have to be more clear. If you are getting -dev straight from cvs, which is updated immediately with all changes, you have the fixes and things should work. If you are picking up the tarball from the project page that has today's date on it, that was rolled before my changes and is *not* fixed. If you use the tarball you have to look at the *whole* date, including the time. If it has a time that is earlier than when I said the problem was fixed, my fixes are not in it.

And now that I look at the project page, I see that the time is not shown, so you can't tell. But the general rule of thumb is that if you are looking at a tarball with today's date on it, it was actually rolled many hours ago, most likely before the fixes were committed, so you'll need to wait for *tomorrow's* tarball to be sure you have today's commits.

Confirmed that the latest tarball on the project page doesn't work, but the latest CVS release does.

For those who have ssh access and cvs installed, you can use the following page for instructions on how to download straight from the CVS:
http://drupal.org/node/321

Actually, if you click on its "Release notes," then you will see the time stamp:

Download: date-6.x-2.x-dev.tar.gz
Size: 526.41 KB
md5_file hash: 6de5afcfacea12af1bbdcaa551a6c836
Last updated: March 26, 2009 - 07:06

Then you can compare it w/ "View CVS messages" (/project/cvs/70963). It seems to be the latest tarball in the project page...

The dev version I downloaded from the repository a few minutes ago is working fine.
Thank you KarenS! (for the fix and for teaching me something new)

I don't understand how to get the latest CVS version, can someone upload the file here?

The instructions on http://drupal.org/node/321 can be followed to download from the repository. Under http://drupal.org/node/321#specific-version you'll find the instructions for a specific version of a contributed module.

Download CVS

Adapting the code given here for the latest development version of the date module:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-6--2 -d date contributions/modules/date

DRUPAL-6--2 is the version tag for the Date module version 2 for Drupal 6.

Try getting it yourself first, to help get the job done in the future!

Here's a tarball for if you're in a fix. I'm not sure if it is appropriate uploading it here, but here goes. I'll delete it in a few days.

EDIT: It seems I won't be able to delete the uploaded file myself.

thank you I am trying to install cvs on my mac but evidently it is huge and will take a while before i can use the shell commands. this is a big help.

thank you I am trying to install cvs on my mac but evidently it is huge and will take a while before i can use the shell commands. this is a big help.

Worked for me ...

I got the latest from the CVS and worked like a charm.

Drupal *ROCKS*

Ok, dev works for me. Hoping to see this in the next stable release, too.

In my opinion, the fix is almost correct -- it will work for strings like "now + 3 hours", but not for strings like "today 3PM", which strtotime() and date_create() can both handle correctly.

I have a more general fix, with patch, in #424006

My problem seems related to this issue:

In the context of a past events block: Can any one confirm or deny that they can get < now to work?

An event I have posted in my upcoming events block shows as expected with:
date filter > now

That same event is showing in my past events block which is set:
date filter < now

nevermind. I removed the date argument that was in the default setting and my block now works as expected.

Sorry for the static.