Issue with time zone + format in DateItem

[Isomorphic]

The necessary changes have been ported to 12.0 and will appear in the next build dated April 9 or later.

Note that you *do* need to setInputFormat("YMD") and install a datetime version of your custom-format, in order for parsing to work properly in both date and datetime items.

[eric.maziade.afsi]

Apologies for the delay in replying - a fix for this was applied some days ago, but only to our 13.0 and 12.1 versions.

We'll port it to 12.0 today.

Thanks. Looking forward to it.

Regards,
--
Eric

[Isomorphic]

Apologies for the delay in replying - a fix for this was applied some days ago, but only to our 13.0 and 12.1 versions.

We'll port it to 12.0 today.

[eric.maziade.afsi]

Using a time zone that shifts to the next date (relatively to the browser time zone) in combination with a custom short display format, we're getting an issue with DateItem.

Locally, we're March 29th.
I'm using a time zone offset of +16:00 (Pacific Fiji) (enough of a difference to make it tomorrow in that time zone)

When I pull up the time picker, the 30th is highlighted - this is perfect, as we are March 30th in Fiji time.

The issue comes when I pick it... once I click on the 30th, the date gets offset a second time... and March 30th ends up being displayed.

Adding DateUtil.setInputFormat makes things even odder- the date gets an extra day bump... and gets an extra day every time the date picker loses focus.

We reproduced it in a testbed under SmartClient v12.0p_2021-03-17:

        
        DateUtil.setShortDisplayFormat('yyyy-MM-dd');
        DateUtil.setInputFormat('YMD');
        Time.setDefaultDisplayTimezone ('+16:00');

        var form = isc.DynamicForm.create({
            numCols : 1,
            width : 300,
            fields : [{
                name : 'message',
                type : 'date',
                editorType : 'DateItem',
                useTextField : true,
                title : 'Date picker'
            }]
        });

        form.show();

Interestingly, the problem disappears if we don't have a custom format... suggesting that the date formatting feature might be re-offsetting the date instead of keeping it as a "logical date" internally.

Regards,
--
Eric