dijit.form.DateTextBox displayed error with 'yy' pattern and fullYear:false

[JamesTung]

I use the dijit.form.DateTextBox? component with the following code :

        <script type="text/javascript">
            dojo.require("dijit.form.DateTextBox");
            function setShortYear() {
                var w = dijit.byId('shortYear');
                w.constraints.fullYear = false;
                w.attr('value', new Date()); //set value is TODAY
            }
            dojo.addOnLoad(setShortYear);
        </script>

        <input id="shortYear" type="text" name="shortYear" dojoType="dijit.form.DateTextBox" constraints={datePattern:'MMddyy'}
        required="true" />

I set pattern to 'MMddyy' and value is TODAY(ex: 11/19/2010). The displayed string in field is correct(111910), but the calendar is wrong(become 01/11/910). The year look like 3 digit.

[Adam Peller]

dojo.date.locale.parse("111910", {fullyear:false, datePattern:"MMddyy",selector:"date"})

Sat Jan 11 0910 00:00:00 GMT-0500 (EST) {}

[JamesTung]

I think this problem maybe made the calendar can't select the dates of AD 99 and before. dojo.date.locale.parse("01/01/0099", {fullyear:true, datePattern:"MM/dd/yyyy",selector:"date"}) Fri Jan 1 00:00:00 UTC+0800 1999

[JamesTung]

Have any update? Could it be fixed in dojo 1.6?

[FrugalGuy]

This bug is causing major issues for my team. It means the dateTextBox cannot be supported in our product. I believe even the samples on dojotoolkit.org won't all work because of this bug.

[Adam Peller]

@FrugalGuy?, I thought this issue was limited to this special case of a date pattern with no separators? Support for dates < 100AD is only supported with strict:true, according to the docs. If there are other cases that don't work, including samples on dojotoolkit.org, please post specific info.

[Adam Peller]

oh, and I don't believe setting the constraints that way on a widget is supported either. Should be documented as [const]?

[Douglas Hays]

This is a regexp problem in dojo.date.locale.parse.
In this example, (0?[1-9]|1[0-2])(3[01]|[12]\d|0?[1-9])(\d{2,4}) is used to parse the date
but it should be (1[0-2]|0?[1-9])(3[01]|[12]\d|0?[1-9])(\d{2,4})
The 2 digit month should have precedence over the single digit month when matching.

[bruceke]

Any plan to fix this defect? We verified with Dojo 1.6 Beta2 and the problem is still exists. We have a high priority defect in our product related to the fix of this. Can you help to update the plan for this? Thanks.

[Adam Peller]

Here's a patch based on Doug's suggestion. Doug, could you please review?

[Adam Peller]

see also #11332, #6242

[Douglas Hays]

The fix looks good

[Adam Peller]

generate multiple digit parts of RE before those with optional leading zero's

[Adam Peller]

(In [23987]) Tune regexps. Fixes #11958 \!strict

[bruceke]

Is it possible to put the fix into Dojo 1.6? Is there a technical reason it can't also be fixed in that release?

[Adam Peller]

No technical reason, we just try to limit backporting to regressions and critical fixes. But it can be considered.

[bruceke]

It is related to a high priority defect in our product, it would be better for us to get it fix in Dojo 1.6 if possible.

[Adam Peller]

@bruceke, please contact me at peller at dojotoolkit dot org

[bruceke]

Replying to peller:

@bruceke, please contact me at peller at dojotoolkit dot org

mail sent.

[Adam Peller]

(In [24219]) apply regexp fix to 1.6 branch. Refs #11958 \!strict