#11512 closed defect (fixed)
A format without 'yyyy' for a DateTextBox breaks the validation
Reported by: | Dom Derrien | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | high | Milestone: | 1.6 |
Component: | Dijit - Form | Version: | 1.5 |
Keywords: | dijit DateTextBox format validation | Cc: | |
Blocked By: | Blocking: |
Description
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
Attachments (3)
Change History (11)
comment:1 Changed 11 years ago by
Component: | Dijit → Date |
---|---|
Owner: | set to Adam Peller |
comment:2 Changed 11 years ago by
Component: | Date → Dijit |
---|---|
Owner: | Adam Peller deleted |
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.
comment:3 Changed 10 years ago by
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.
comment:5 Changed 10 years ago by
Owner: | set to Douglas Hays |
---|
comment:6 Changed 10 years ago by
Milestone: | tbd → 1.6 |
---|
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.
comment:7 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [23332]) Fixes #11512. Create automated test to show that no year requires a user-defined parse method. Tightened up compare() in DateTextBox?.
comment:8 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
Sounds like an issue w/the underlying Date code so assigning to Adam.