Community
Participate
Working Groups
IBM JDK 5.0 SimplyMEPIS 6.0 - Linux 2.6.15-27-686 Eclipse 3.3.0 (gtk2 version) --- 1. extract some project from cvs 2. right-click the project and select Replace With > Another Branch or Version... 3. click Add Date... 4. type 5 in the first field (month) 5. click in second field (day), then type 14 6. check the [x] Include time component in tag field 7. click in first field (hour), then type 10 8. click in second field (min), then type 58 9. click in third field (sec), then type 0 10. click on AM/PM field, then type a 11. (*) Time is local 12. Date added is "14 Jul 2007 10:58:00", but month 5 = May, not July (today's date) I've also encountered problems when zeros are entered for time values: As above, enter the datetime: 3/12/2005 12:00:00 am which becomes "12 Jul 2005 00:07:07" 3/12/2005 12:00:00 pm which becomes "12 Jul 2005 12:00:35" In other words, when the value is unacceptable (for some unknown reason), it defaults to the CURRENT time/date value rather than accepting the values given. Essentially, it makes this wizard nearly unusable.
Further testing shows that to make the wizard work you have to enter two-digit values, like "00" or "05". This suggests that the fix here ought to be making the wizard SHOW the extra "off camera" zero digits instead of them magically appearing/disappearing. There's nothing wrong with showing "07/23/2007" instead of "7/23/2007" and in terms of the time component, it's *MORE* accurate to show "03:15:05 PM" than " 3:15: 5 PM". This would make it obvious what the dialog's fields contain and therefore would avoid the "I entered a 5 and got a 7" problem. It would also be nice to add some trivial validation so that if I enter "5" and the wizard "thinks" I've entered "75" because of the previous value, that when I hit OK it complains that "75" is not a valid month, instead of just giving me "7" when I asked for "5".
Tomek, can you please investigate. I am curious to know whether this is Linux only or if the problem is on Windows as well. If it's Linux only, it may be a problem in the SWT Date/Time widget.
Confirmed: I was able to reproduce it _only_ under Linux (N20070717-1020). The dialog under Windows (N20070723-0010) works fine.
After some debugging done I can affirm that under Linux the DateTime widget returns invalid values.
I followed the steps in comment 1 here is a comparison of values returned by the widget on both Linux and Windows. I hope it will shed some light on the way how the widget behave under Linux. The values are listed as follows: widget.getYear() widget.getMonth() widget.getDay() widget.getHours() widget.getMinutes() widget.getSeconds() First test case from comment 1 (14 May 2007 10:58:00): On Linux 2007 6 14 10 58 17 On Windows 2007 4 14 10 58 0 Second (3/12/2005 12:00:00 am): On Linux 2005 6 12 0 0 9 On Windows 2005 2 12 12 0 0
I think this got fixed in 3.4 but I'll have to check...
Here's a case that still fails in the latest: - run the snippet below - change the first date component (the month) to a different single-digit value like "3" - click on the middle date component (the month) and note that nothing was written to stdout, so no Selection event was sent - press the up or down arrow to change the day value and note that the original month value-1 is written to stdout because it did not "commit" the value that was previously entered - this scenario can be made to work by the user by either right-arrowing from the month field to the day field (instead of mouse-clicking over to it), or by entering the month as a two-digit value (eg.- "03") public static void main(String[] args) { final Display display = new Display(); final Shell shell1 = new Shell(display); shell1.setLayout(new FillLayout()); shell1.setBounds(10, 10, 300, 300); final DateTime dt = new DateTime(shell1, SWT.DATE); dt.addSelectionListener(new SelectionAdapter(){ public void widgetSelected(SelectionEvent e) { System.out.println(dt.getMonth()); } }); shell1.open(); while (!shell1.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
This is still reproducible.
Move out of 4.7 and reassign to Eric.
Looking into this further it's possible that I misread comment 7. Here are my observations running that snippet: From what I can tell, the snippet in comment 7 is supposed to print the month whenever the SelectionListener is triggered (i.e. whenever a value is changed). Using the snippet I am getting print statements whenever I change any of the values -- including single or double digit months. The print statement happens right away without having to move to the next field. AFAIK this is correct behaviour. I'll leave this open for a bit, if no one objects after awhile then I will close it.
