Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#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)

dateTextBoxBugPatch.txt (1.3 KB) - added by Samuel B. Johnson 8 years ago.
Patch for _DateTimeTextBox
dateTextBoxBug.html (1.4 KB) - added by Samuel B. Johnson 8 years ago.
Simple Test file for patch
11512.patch (4.5 KB) - added by Douglas Hays 8 years ago.
test showing how parse can be enhanced

Download all attachments as: .zip

Change History (11)

comment:1 Changed 9 years ago by bill

Component: DijitDate
Owner: set to Adam Peller

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

comment:2 Changed 9 years ago by Adam Peller

Component: DateDijit
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 8 years ago by 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.

Changed 8 years ago by Samuel B. Johnson

Attachment: dateTextBoxBugPatch.txt added

Patch for _DateTimeTextBox

Changed 8 years ago by Samuel B. Johnson

Attachment: dateTextBoxBug.html added

Simple Test file for patch

comment:4 Changed 8 years ago by Samuel B. Johnson

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

comment:5 Changed 8 years ago by Douglas Hays

Owner: set to Douglas Hays

comment:6 Changed 8 years ago by Douglas Hays

Milestone: tbd1.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.

Changed 8 years ago by Douglas Hays

Attachment: 11512.patch added

test showing how parse can be enhanced

comment:7 Changed 8 years ago by Douglas Hays

Resolution: fixed
Status: newclosed

(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 8 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.