These objects are not available for public use (you cannot construct one and use it), instead these objects are created by the input assist behaviors.
The following description provides an outline of how DateTime assist processes keystroke, mouse and clipboard interactions when it is applied to an input field containing a DateTime string.
When the field receives focus, the value is transformed to "input format", it is coerced to be a correct value and prompt characters replace leading zeroes, the result is displayed and the cursor is positioned before the first input position.
The "input format" of a datetime is constructed based on the datetime's format. All date components that are not y, G, M, d, h, H, m or are removed from the format and all "textual" components (components that use three or more letters) are turned into numeric components (e.g., MMMM becomes MM). All single character components are turned into two character components (e.g., d becomes dd). Year components are transformed to be either yyyy or yy. Epochs are converted to either literals (if the epoch cannot be changed as is the case in the Hijiri, Hebrew and Buddhist calendars) or to allow the leading character to be input (as is the case of the Christian and Japanese Gregorian calendars) The result is a input format that contains only "numeric components" which uniquely determine a date value (except the epoch which if present is an single character). The value is converted to the input format and coerced to be correct (if not null). Coercion replaces any incorrect component with the appropriate component from "today's date" adjusted for bounds. For example, if the month is "14" and it is currently September, the month is changed to "09". If the month is "02" and the date is "31" and today is September 30th, the date is changed to 28 (or 29), that is, it's changed to "30" and the 30 is then bounded to 28 (or 29) as February does not have 30 days.
For example, given the DateTime format of EEEE MMMM dd,yyyy the input format is " MM dd,yyyy". If the value is September 31, 2003, it is converted to the input format (09/31/2003) and then coerced resulting in the display "*9 30, 2003".
When the field loses focus, prompt characters are removed from the field, the value is coerced to be a correct value (thus it is always 'correct' after onblur) and the value reformatted using its (original) format. "Coercion" in onBlur is the same as coercion in onfocus. Note that prompt characters are simply "removed" from the field (not replaced with zero), so if the prompt character is * and a component is left as "19**", the value of the component is "19" (not "1900").
When a digit key is pressed (that is a keypress event is generated), if the cursor is positioned before an input position, the resulting date component is bounds checked, and if the result is valid the character (or prompt character) at the cursor position is overwritten OR the first character in a selection is overwritten (and the remaining characters in the selection set to the prompt character). For example, if the cursor is before the * character in the month component "*3" and the user presses 1 the result is invalid (the component cannot have the value 13) while if zero is entered the component is valid (03 is a valid month) and the zero overwites the prompt character. Then, the cursor is advanced to the next position where a user may type (or the end of the field). If an invalid key is pressed, "nothing happens". If an epoch is present (and editable), and the cursor is positioned at the first character of the epoch, pressing an appropriate character (e.g., A or B in the case of the Christian character) fills in all the epoch characters (e.g., pressing A fills in AD) and the cursor advances to the next editable position.
There are some somewhat complicated issues that arise because what constitutes a valid component may be dependent on another component. For example, consider the date MM/DD/YY and the user wants to type 11 30 06. If the date is blank initially, the user can simply type 11 30 06. But if the date is initially 12/31/06, then if the user types 11 the value "31" is no longer valid (November can't have 31 days). When an inter-component dependency exists rather than "blocking" a user from typing (e.g., not allowing the user to type "11"), we "clear" the characters that would be invalid. So if a user types 11, we'll clear the 31 and allow the 11 to be entered. These dependencies can exist even within a single part of a date component. For example, suppose the month is "09". If a user types "12", we'd have a problem after the user types "1" as "19" would not be a valid month. Again, we clear the problematic character rather than blocking input (so when the user types "1", the 2 will be blanked out). Interdependencies exist within the two characters that make up a date, the two characters that make up a month, the days per month, the months in a year (in the Hebrew calendar), and the year (whether a year is a leap year or not or complete, regular or deficient in a Hebrew calendar).
When a control key is pressed (that is a keydown event is generated with a control key indicated in the keycode), DateTimeAssist processes the control key on the keydown event (this is the norm in Windows®). If the control key is a right arrow, the cursor is advanced to the next position in the string where input can occur. If the left arrow is pressed, the cursor is moved "back" to immediately after the previous position where input can occur (thus input may not be possible until left arrow is pressed again -- this allows for positioning the cursor where the backspace key will work). If the Del key is pressed, the character after the cursor position is deleted (or the selection if one is present), and the cursor advanced. If the backpace key is pressed, the character before the cursor position is deleted and the cursor moved back. If tab or enter are pressed, the normal form processing actions are taken. No other control keys are processed specially (e.g., HOME and END are not processed specially but they work as expected.
If the user clicks in the field (and the click is not part of a selection), the cursor is positioned before the "next" character where a user may type.
Cut/Copy/Paste interactions are only handled in IE (Mozilla does not support this) and only limited support can be provided in IE (while it provides a full set of events for managing interactions, IE has only limited access to the clipboard itself which restricts what can be done).
Copy copies the selection to the clipboard verbatim. Cut does the same except it clears the selection (sets all input positions to blank). On a paste, if it appears that the value on the clipboard was a DateTime string, the "input" characters (non-literal) characters only are pasted otherwise the entire string is pasted. The paste applies characters only to "input" positions (skips literals). If any character fails input validation, the entire paste is cancelled otherwise the cursor is put at the end of the pasted characters (though the browser sometimes then moves the cursor position).