Filtering confusion

[designermonkey]

I am trying to allow a date range for publishing an entry. The user can enter the publish dates as a single from date, or select a range to start and end.

If the user doesn't select and end date, then the same dat that was chosen for the start is stored in the field.

This breaks filtering as I can't do start: earlier than now + end: later than now being that end is the same as start.

I'd rather not have two date boxes to allow a start and end date selection for filtering. Am I doing something wrong here?

[nilshoerrmann]

What about strict: now? (see docs)

[designermonkey]

Doesn't work :(

[designermonkey]

I've had a good old look through the filtering for this field, and there's nothing wrong there. The problem is that the user is not selecting an end date, yet one is being stored in the field's table.

This doesn't sound right to me. As the filters are using default start and end dates of

1000-01-01 00:00:00
9999-12-31 23:59:59

then shouldn't the default end date be applied to the field in absence of a selected one? That way all filtering attempts would work correctly as expected in all variations, when an end date is not specified.

[designermonkey]

Line 625 of field.datetime.php should be $result['end'][] = '9999-12-31 23:59:59' IMO

What do you think Nils?

[designermonkey]

Ah, but this makes the calendar select the entire future. Damn.

[nilshoerrmann]

Have you tried extended: now?

[designermonkey]

I will, that one really confused me. Does extended allow an end date to be filtered also?

[nilshoerrmann]

The problem is that the user is not selecting an end date, yet one is being stored in the field's table.

This is correct behaviour: If you select only a single date, you are specifying an exact moment in time thus start and end should be the same (which is why the field stores the start as end as well).

I will, that one really confused me. Does extended allow an end date to be filtered also?

I never used the extended filter myself but it should just take single date as the starting point for an endless range: start to infinity. This sound like what you are after with your proposed change in line 635.

[designermonkey]

I've actually decided to change to having two separate fields for this, as I just can't get it to work.

Now I have the problem that I can filter the from field perfectly, but if I add no date into the to field, and specify a filter, it returns no results, as the field has no date in it.

I'm really at a loss as to how to achieve this, no solution works here.

[nilshoerrmann]

• Does the filter you need exist and doesn't work?
• Or does is just not work?

Your posts don't really give me a clue. If something needs to be fixed, we can fix it. If a filter is missing, we can add it.

[designermonkey]

I need to allow a user to add a date to publish from, and optionally add a date to un-publish the entry. The from date is no issue at all.

However I try and do the un-publish date, whether it be a range from start to end in one field, or a separate field, it won't allow me to filter it as it is an optional date. If a date is entered somewhere in the future, then it filters fine, but if they want the entry to never be un-published, they won't add a date, or won't select an end date, and that's where the filtering isn't working. If a filter is applied to a field that has no value or an end date that is the same as the start, it returns nothing.

The range filtering only works if there are two values, as not specifying an end date adds the start as the end too, which means the entry will never display as the end has already passed.

Single field range I would expect to work with optional end date (works with a future end date):

start: earlier than now + end: later than now

Single field dates I would expect to work:

earlier than now (in the publish from field)
later than now (in the un-publish field)

The filters that make this scenario fail are: end: later than now and later than now as the field either has the same start date, or no date.

[designermonkey]

So, it seems that extended does do the job.

I would like to re-write the explanation for you as it doesn't read like that for me.

Sorry for wasting your time @nilshoerrmann you know I appreciate your help though o_O

[nilshoerrmann]

No worries, John.

I have neither added nor used the extended filter so if you have a better explanation, please post it here or send a pull request. Thanks!

[nilshoerrmann]

John, I've been thinking about your problem over the last days and maybe the syntax should be adjusted and extended to ease filtering. What about this?

Filter Keywords

In addition to the filter keywords inherited from the core date field (earlier than/later than) we could add two new keywords:

• is single which will only return true for – well – single dates and
• is range which will only return true for date ranges.

These keywords could be connected to other relative date filters using and.

Filter Prefixes

The filter prefixes could be simplified:

• no prefix will check if either start or end date match the given condition
• start: will only check if the start date matches the given condition
• end: will only check if the end date matches the given condition
• between: will check whether start and end date match the given condition

The latter replaces the current strict: prefix, extended will be dropped.

So your desired filtering could be written like this:

is single and earlier than now, is range and end: later than now

(Not sure about the placement of the end: yet). Different notation but same result:

is single and earlier than now, now to 9999-12-31 23:59:59

What do you think?

[nilshoerrmann]

Maybe it would even be better to rename start to starts and end to ends. This could give us real sentences:

is between now and +1 month, is range and ends later than now

So the prefixes would become simple keywords like earlier than and the like.

/cc @brendo

[nilshoerrmann]

Any comments by you on this proposal, @designermonkey and @brendo?

[brendo]

It'd be very cool. I'm fortunate to have never needed very complex date filtering but for those who do I'm sure it'd be welcomed. I wonder how much of this natural language PHP can already parse?

[nilshoerrmann]

What about renaming or removing the keywords start:, end:, strict: etc.?

[brendo]

You'd need them for backwards compatibility, but aside from start:, end: (which are obvious) the rest are a little confusing (not memorable by any means) even though they definitely have specific use cases.

[nilshoerrmann]

Personally, I'd think of this as a breaking change (= version 4.0) not offering backwards compatibility. My question was more about removing the : from the prefixes and moving to natural language.

I wonder how much of this natural language PHP can already parse?

I don't know – the problem is that this needs to be transformed into a MySQL query, so I'm not sure how PHP will help here …