A format without 'yyyy' for a DateTextBox breaks the validation

[Dom Derrien]

I had troubles while trying to set a min constraint to a dijit.form.DateTextBox? field. I found a work-around by accident.

I had the field: <input constraints="{datePattern:'EEE, MMMM dd'}" dojoType="dijit.form.DateTextBox" id="date" name="date" required="true" type="text" />

In a dojo.ready() function I was doing:
var yesterday = new Date();
var tomorrow = new Date();
yesterday.setDate(yesterday.getDate() - 1);
tomorrow.setDate(tomorrow.getDate() + 1);
var dateField = dijit.byId("demand.date");
dateField.set("value", tomorrow);
dateField.constraints.min = yesterday;

Then the widget was always reporting an invalid date!!! I commented out the min contraint setting and continued my development.

At one point, I read the value with dijit.byId("demand.state").get("value") and I've been surprised to see the year set with 1970!!! When I changed the date format to "EEE, MMMM dd yyyy", suddently everything worked, the min constraint included! The default date format for the field displays the year, which my explain why the bug has not been captured.

I started to move my code to 1.5 recently (replacing attr() calls by get() and set(), for example), so I cannot verify it can be reproduced with 1.4, but I think it was present in 1.4...

I'm going to study the code. Maybe I'll be able to propose a patch.

A+, Dom

[bill]

Sounds like an issue w/the underlying Date code so assigning to Adam.

[Adam Peller]

I think dojo.date is behaving in a reasonable way. Unspecified fields should default to unix epoch or something close (I suspect it's actually using the wrong timezone, or we might see 1969...) The problem, I think, is that DateTextBox expects the string to round-trip between format and parse, and without the year info, this is not complete. For month/day, what do you do about leap years, days of the week? Would it be valid to use only the day of the month in your format? I'm not sure we want to support the use case above, but we should try to better define exactly what we do support.

[Samuel B. Johnson]

Based on what peller pointed out, I created a patch for _DateTimeTextBox. Rather than make the comparison against the given minimum, I made the comparison against a version of the minimum that had been formatted in the same way as the specific DateTextBox?. That means that the minimum would share any default values given, making legitimate comparisons possible. Although I only tested it in this case, in theory it should also allow DateTextBox? to make valid comparisons, even if the format only specifies day of the week, or day of the month, or month.

[Samuel B. Johnson]

Patch for _DateTimeTextBox

[Samuel B. Johnson]

Simple Test file for patch

[Samuel B. Johnson]

It was also suggested to me that I note that I've signed the CLA.

[Douglas Hays]

I agree with peller that we don't need to support this in the DateTextBox? widget. This scenario can be accomplished by extending the parse method to fill in an appropriate year. I'll use this ticket to add a testcase for this to make sure it works.

[Douglas Hays]

test showing how parse can be enhanced

[Douglas Hays]

(In [23332]) Fixes #11512. Create automated test to show that no year requires a user-defined parse method. Tightened up compare() in DateTextBox?.