Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 315950

Summary: [DateTime] method getDay() return wrong day in particular circumstances
Product: [RT] RAP Reporter: marco <c1028681>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daria.spam, m.kempe
Version: 1.3   
Target Milestone: 1.4 M1   
Hardware: All   
OS: All   
Whiteboard: sr132
Attachments:
Description Flags
Patch against v13_Maintenance ivan: review?, rsternberg: review+

Description marco CLA 2010-06-07 06:31:18 EDT 
Build Identifier: I20090611-1540

On the control DateTime created with constraints SWT.DATE | SWT.DROP_DOWN, selecting on the calendar the month of June, and then selecting the first day visible on the calendar box (in this case the last day of May, the 31 in gray), the DateTime control show correctly 31/05/2010 but the method getDay() on the dateTime control return wrongly 7.
However the control return the correct day if the 31th of May is selected from the May month view.

Reproducible: Always

Steps to Reproduce:
1. Create a DateTime control with constraints SWT.DATE | SWT.DROP_DOWN
2. Open the calendar view, go to June month of 2010 and select the first day visible in gray, the 31 of May
3. The control show correctly 31/05/2010
4. read the day from code using the method getDay(), it return 7 instead of 31
Comment 1 Bassspieler CLA 2010-06-24 08:01:22 EDT 
It always happens, when you choose a "day", that has not existed in the month you are "coming from". "Always" applies to: when you type the digits directly into the widget.

Initial date: "xx.02.2010"
Target date: "30.01.2010" or "31.03.2010" or "29.04.2010" and so on

Exact steps:
Just click the month-digits and type "01" for january, then click the day-digits and type "30" or "030" for the 30. of january.
The date is correctly displayed, but wrong returned via getDay() from the control.
Comment 2 Ivan Furnadjiev CLA 2010-06-29 05:16:42 EDT 
The problem was in DateTimeDateLCA where the new date was set field by field in readData(). Fixed in CVS HEAD. JUnit test added.
Comment 3 Ivan Furnadjiev CLA 2011-02-01 08:05:39 EST 
*** Bug 335948 has been marked as a duplicate of this bug. ***
Comment 4 Ivan Furnadjiev CLA 2011-02-01 08:31:01 EST 
Created attachment 188040 [details]
Patch against v13_Maintenance
Comment 5 Ivan Furnadjiev CLA 2011-02-01 08:38:18 EST 
*** Bug 335948 has been marked as a duplicate of this bug. ***
Comment 6 Ralf Sternberg CLA 2011-02-03 17:39:17 EST 
Comment on attachment 188040 [details]
Patch against v13_Maintenance

I consider this patch safe to go even into 1.3.2 RC3. The bug causes data inconsistencies and the fix involves no risk.
Comment 7 Ralf Sternberg CLA 2011-02-08 06:15:00 EST 
Applied patch to v13_Maintenance branch after discussion with Rüdiger.