Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

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

5465.patch (690 bytes) - added by Douglas Hays 11 years ago.
add if statement to locale.js to workaround this problem

Download all attachments as: .zip

Change History (14)

comment:1 Changed 11 years ago by Adam Peller

Milestone: 1.0.3
Owner: set to Adam Peller
Summary: Problem with dijit.form.DateTextBoxCentury confusion with dijit.form.DateTextBox

comment:2 Changed 11 years ago by Adam Peller

Cc: Douglas Hays added

the validation code must be reparsing the text as if it were user input and overriding the actual Date value

comment:3 Changed 11 years ago by Adam Peller

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 11 years ago by Douglas Hays

Cc: bill added
Resolution: wontfix
Status: newclosed

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 11 years ago by Adam Peller

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 11 years ago by Adam Peller

Milestone: 1.0.3
Resolution: wontfix
Status: closedreopened

another option is to just use 4-digit years all the time

Changed 11 years ago by Douglas Hays

Attachment: 5465.patch added

add if statement to locale.js to workaround this problem

comment:7 Changed 11 years ago by Douglas Hays

Owner: changed from Douglas Hays to Adam Peller
Status: reopenednew

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

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 11 years ago by Adam Peller

Status: newassigned

comment:10 Changed 11 years ago by Adam Peller

(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 11 years ago by dylan

Milestone: 1.0.31.1
Priority: highnormal

comment:12 Changed 11 years ago by Adam Peller

Resolution: fixed
Status: assignedclosed

comment:13 Changed 8 years ago by bill

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