When creating a date range, 4-digit values get treated with special behavior.
For example, when creating a cck field, the instruction is

Number of years to go back and forward in the year selection list, default is -3:+3.

However, if either end of the range is 4 digits it is treated as an absolute-year value, and no longer a range.
(In other words, "-1000:+1000" will display the years -1000 to 1000, instead of 1000 years previous and 1000 years into the future.)
This is because the regex in date_range_years() overzealously matches any 4-digit number, regardless of whether it's range with absolute or relative values.
The current behavior does not match the documentation for this function (nor is the 4-digit-range option exposed in the instructions for setting date ranges, but that's for another issue).

This applies to both 7.x-2.x and 6.x-2.x.

Comments

aaronbauman’s picture

StatusFileSize
new522 bytes
aaronbauman’s picture

Status: Active » Needs review
StatusFileSize
new558 bytes
karens’s picture

/me wonders why anyone would want to display 1000 years in a drop down selector. I suppose we can make it possible but I can't really imagine a reasonable use case.

I would prefer a patch that fixes the documentation. People keep posting reports that its broken but no one supplies patches for that.

aaronbauman’s picture

I don't think it should be necessary to defend a bug fix against an argument about whether the use case is reasonable, but here it is:
Suppose one only wanted to display only a handful options in a dropdown, with relative dates in a range of over 1000 years:
"-2050:-1950"
or "+1000:+1005"
This is currently impossible, and such an input results in unexpected results.
The above inputs would generate, respectively, an option list of values -2050 to -1950 and 1000 to 1005.

Documentation needs to be updated whether this bug gets fixed or not, but until a clear path forward is decided upon (ie. whether to support 4-digit ranges or not), it's not clear how the documentation should be updated.

karens’s picture

Status: Needs review » Fixed

The above inputs would not result in a range of -2050 to -1950, they would result in a range of something like -4061 to -3961 (the +/- values are relative to the current year).

I have no idea which 'documentation' you think needs to be fixed. If you see problems with the embedded documentation, please provide a patch. If you are talking about something else, please make that clear.

OK, I made this change.

aaronbauman’s picture

Version: 7.x-2.x-dev » 6.x-1.x-dev
Status: Fixed » Needs review

reopening against d6.
(see patch in comment #1).

crossposting documentation patch
#1335686: Update date range documentation to expose support for 4-digit absolute year ranges

aaronbauman’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev

fixed version.

arlinsandbulte’s picture

Status: Needs review » Fixed

This is now working in the latest version of Date.
We'll handle the docs issue in #1335686: Update date range documentation to expose support for 4-digit absolute year ranges

aaronbauman’s picture

Status: Fixed » Needs review

Nope, sorry.
This patch has not been applied, the regex is still wrong, and date_range_years() has not changed.
Maybe you misunderstood the OP?

aaronbauman’s picture

StatusFileSize
new29.02 KB
new14.73 KB

Hopefully these screenshots will more clearly illustrate the issue.

Assume I want a date field that allows users to select between the years "1005 years ago" and "1000 years ago".
According to the documentation, the date range year format "-1005:-1000" should accomplish this:

The expectation is that the values displayed will be 1007 through 1012.
However the setting above results in the values -1010 through -1000 being available for selection in the year field:

aaronbauman’s picture

bump

damienmckenna’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.