#5465 closed defect (fixed)
Century confusion with dijit.form.DateTextBox
Reported by: | guest | Owned by: | Adam Peller |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Dijit - Form | Version: | 1.0 |
Keywords: | Cc: | bill | |
Blocked By: | Blocking: |
Description
The following html shows how I defined the DateTextBox? when you click on the textbox the calendar is set to 2006 and not 1906.
<input id="admDate1" dojoType="dijit.form.DateTextBox?"
constraints="{formatLength: 'short'}" value="1906-10-05" />
Attachments (1)
Change History (14)
comment:1 Changed 13 years ago by
Milestone: | → 1.0.3 |
---|---|
Owner: | set to Adam Peller |
Summary: | Problem with dijit.form.DateTextBox → Century confusion with dijit.form.DateTextBox |
comment:2 Changed 13 years ago by
Cc: | Douglas Hays added |
---|
comment:3 Changed 13 years ago by
Cc: | Douglas Hays removed |
---|---|
Owner: | changed from Adam Peller to Douglas Hays |
given that this is a validation thing and the relative size of our bug queues, Doug, can you take a look? Not sure this really has to be a 1.0.3 thing, but given the potential for data loss, even if it's an edge case, let's see what the fix looks like and consider for the branch?
comment:4 Changed 13 years ago by
Cc: | bill added |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
I don't see how this can be fixed. If we display 12/31/06 (meaning 1906) and the user changes 12 to 11 we're still going to reinterpret the string and parse() will return 2006. Additionally, InlineEditBox? has worse problems. The user should use long format if a wide range of years is desired.
comment:5 Changed 13 years ago by
Milestone: | 1.0.3 |
---|
hmm... seems like a tough situation. We could finesse the logic that picks default centuries, but I really don't think it's worth the bloat. Though I'd feel a bit better about it if the data weren't changed at all if the user doesn't make any edits.
comment:6 Changed 13 years ago by
Milestone: | → 1.0.3 |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
another option is to just use 4-digit years all the time
Changed 13 years ago by
Attachment: | 5465.patch added |
---|
add if statement to locale.js to workaround this problem
comment:7 Changed 13 years ago by
Owner: | changed from Douglas Hays to Adam Peller |
---|---|
Status: | reopened → new |
Please evaluate the attached patch. It changes format to automagically switch to 4 digit years only when there would be a subsequent parsing problem if 2 dijit years were used instead. There's no change to the RFC value submitted to forms.
comment:8 Changed 13 years ago by
To be honest I'd prefer to just always display a four digit year. Otherwise developers need to know to make the input box big enough to hold a four year value, even though usually it just displays a two year value.
comment:9 Changed 13 years ago by
Status: | new → assigned |
---|
comment:10 Changed 13 years ago by
(In [12271]) Always format as 4-digit year in dijit.form.DateTextBox?, but continue to allow 2-digit year input where appropriate. Refs #5465 !strict
comment:11 Changed 13 years ago by
Milestone: | 1.0.3 → 1.1 |
---|---|
Priority: | high → normal |
comment:12 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:13 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
the validation code must be reparsing the text as if it were user input and overriding the actual Date value