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

Bug 525682

Summary: [DateTime] Setting day, month, year may lead to wrong date on the client
Product: [RT] RAP Reporter: Wim Anckaert <wian>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: ivan
Version: unspecified   
Target Milestone: 3.4   
Hardware: All   
OS: All   
See Also: https://git.eclipse.org/r/#/c/110115/
Whiteboard:

Description Wim Anckaert CLA 2017-10-06 10:07:33 EDT
Hi,

Use case:
We have a general date widget datetime : SWT.CALENDAR for all our dates in a popup.
In one case we want to set the birthdate of a person running RAP on a mobile device.
You need a lot of clicks to get to, for example 1971.

So we created two comboboxes above the datetime to change year and month. So the user has multiple options for change the year and month.

That works ok !

We found what i think is a bug.
If the date is set to 2017/03/31 (YYYY/MM/DD) and via the combobox we change it to februari, we want it to be the first of February, but in the gui we see the first of March.
If we ask the datetime wich date is selected, it says first of February. So the widget is correct but it shows the wrong month.

see below a basic snippet to reproduce the problem.
We use RAP 3.1.1, I don't know if it also occures in RAP 3.2


[code]
final DateTime dateTime = new DateTime(parent, SWT.CALENDAR);
            dateTime.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true));

            Button button = new Button(parent, SWT.PUSH);
            button.setLayoutData(new GridData(SWT.BEGINNING, SWT.CENTER, false, false));
            button.setText("Change date");
            button.addSelectionListener(new SelectionAdapter() {
                @Override
                public void widgetSelected(SelectionEvent e) {
                    dateTime.setDay(1);// first day of month
                    dateTime.setMonth(1);// to february

                    // strange thing : we get the correct date that is just set, but gui is not ok.
                    System.out.println("new date:" + dateTime.getYear() + " " + dateTime.getMonth() + " " + dateTime.getDay());
                }
            });

            dateTime.setYear(2017);
            dateTime.setMonth(2);// march
            dateTime.setDay(31);// last day of month

            dateTime.addSelectionListener(new SelectionListener() {

                @Override
                public void widgetSelected(SelectionEvent e) {
                    System.out.println("selected:" + dateTime.getYear() + " " + dateTime.getMonth() + " " + dateTime.getDay());

                }

                @Override
                public void widgetDefaultSelected(SelectionEvent e) {
                    System.out.println("def selected:" + dateTime.getYear() + " " + dateTime.getMonth() + " " + dateTime.getDay());
                }
            });
[/code]


extra info from Chris Fairhall (see forum post :https://www.eclipse.org/forums/index.php/t/1089253/)

Looks like an issue with the ordering of the commands in the JSON protocol.

It doesn't matter which value you set first or how (via setMonth, setDay, setDate) the month property goes first, followed by the day

["set","w1034",{"month":1,"day":1}]

Calling setMonth on a JS date object causes the date value to roll over until the date is valid
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setMonth
Before setMonth is called the date is 2017-03-31
Calling setMonth to Feb changes it to 2017-02-31, which when rolled forward makes 2017-03-03

setDay is then called, making it 2017-03-01

Perhaps the JSON API needs changing to either enforce the correct ordering or to call a single setDate method instead of individual day/month/year methods.

Either way it's a bug and should be logged as such.
Comment 1 Ivan Furnadjiev CLA 2017-10-06 10:44:03 EDT
I'm positive that the issue is fixed in RAP 3.2/3.3. Please confirm the issue with RAP 3.3.
Comment 2 Ivan Furnadjiev CLA 2017-10-16 03:17:40 EDT
Just checked it with RAP 3.3 and I can confirm the issue.