Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
| Dev |
|
| QA |
|
| Priority | Low |
| Complexity | Complex |
| Component | Editor - Debugger |
| Version | 12.0 |
We need to support milliseconds, and date time entry by the current locale.
Note, we can use the method : TimeUtil.getTimestampByPatternCloseMatch(dtFormat.toPattern(), value)
|
|
7 KB
|
|
78 KB
|
|
71 KB
Milliseconds are supported only by the java.sql.Timestamp data type.
java.sql.Date has no concept of time (no hours, minutes, seconds, or milliseconds), while java.sql.Time allows for granularity down to seconds.
Questions:
1. parameter Mode column shows "IN", "IN/OUT". Should it be localized?
Questions:
1. parameter Mode column shows "IN", "IN/OUT". Should it be localized?
Implemented the following workflow:
1. an input dialog is presented to the user, which accepts the local date/time format (including the 'Format' spec column). This format is defined by preferences set in Options -> General -> Appearance.
2. The timestamp (or date+time) data types also support optional milliseconds.
3. the user enters a local string which will be remembered (as well as saved)
4. the code packages all that into a special object ExecValueHack which it then passes to the legacy code.
I've structured this to work as much like the old code, including handling of erroneous and malformatted input.
Implemented the following workflow:
1. an input dialog is presented to the user, which accepts the local date/time format (including the 'Format' spec column). This format is defined by preferences set in Options -> General -> Appearance.
2. The timestamp (or date+time) data types also support optional milliseconds.
3. the user enters a local string which will be remembered (as well as saved)
4. the code packages all that into a special object ExecValueHack which it then passes to the legacy code.
I've structured this to work as much like the old code, including handling of erroneous and malformatted input.
The dialog shows the format as "Default". The user needs to actually know the format.
The dialog shows the format as "Default". The user needs to actually know the format.
Two issues ..
1. If the parsing of the data fails, we need to prompt the user if the format is incorrect.
2. For Saving and Loading we will need to find a way to have backward compatibility.
To reproduce #1 ...
1. debug procedure NielsDateTime on Sybase 15.5 - example_data
2. Step to start debugger and type incorrect date as "44/44/44 5:6:7", then hit enter.
Two issues ..
1. If the parsing of the data fails, we need to prompt the user if the format is incorrect.
2. For Saving and Loading we will need to find a way to have backward compatibility.
To reproduce #1 ...
1. debug procedure NielsDateTime on Sybase 15.5 - example_data
2. Step to start debugger and type incorrect date as "44/44/44 5:6:7", then hit enter.
added audi-visual notification of a parsing error.
added audi-visual notification of a parsing error.
Had to completely re-write this code.
All issues should be fixed now.
See also #6114
Had to completely re-write this code.
All issues should be fixed now.
See also #6114
should work now.
also decided not to rely on background alone to communicate parsing error, added a status icon.
should work now.
also decided not to rely on background alone to communicate parsing error, added a status icon.
Issue #6107 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| No fixed build |
| No time estimate |
Milliseconds are supported only by the java.sql.Timestamp data type.
java.sql.Date has no concept of time (no hours, minutes, seconds, or milliseconds), while java.sql.Time allows for granularity down to seconds.