OCI 7.3.1 w/ SP2 date format issue

[gmilazzoitag]

Hi everybody,

a customer of mine has discovered this today.

Inputing a date range using calendar popup this is provided as the international settings of his client (in this case italian) but then the date in the field is given in MM/DD/YYYY, so if from calendar i.e. is april 5th in the fiegd it becomes may, 4th...or for day values bigger than 12 it generates an error.
In other words nevertheless form calendar a day of the month is selected that number is inputed in the field as a month.

Is there a setting somewhere on OCI server to avoid this?
I've tried to change the international date settings on OCI server but nothing change. In the webui the name of the months continue to be printed in english and the error above still persist, if I choose from calendar december 30 in the field it fills 30/12... with that red error message.

I've also done another test using the JavaUI. If the date settings on OCI server a date choosen from a calendar (i.e. a task) is reprinted as MM/DD/YYYY but if the settings are Italy the date choosen is printed as DD/MM/YYYY.
 
So it seems some form of bug in OCI. 

Regards,

 

These are the result from the JavaUI. Setting italian format gives back the date choosen in that format, vice versa is US date are set. That is possible with the right results in the JavaUI but has no effects in the WebUI, also if this is opened from the server itself.

[ostiguy]

I think this sounds like a bug. I will open one

[gmilazzoitag]

Hi Matt,

maybe. I've posted further informations form test conducted just now on the LOD, nevertheless there I've only english OS I've modified the date settings.
Interesting the results from the old JavaUI.

Customer is running 7.3.1SP2, while LOD has a 7.3.0. I've noted on the LOD server that nevertheless the date is printed as MM/DD it does not generate error. So that I can choose, whatever the settings are, dec. 28 and it will print on the field 12/28. At the customer site if dec. 28 is choosen by calendar is printed as 28/12 but it gives the error because 28 is a month.

Bye

[Miles_Kniep]

I believe this should have been solved in 7.3.2 as part of work done on IFR-3654 & ICI-5189 that addressed non-US locale settings in browsers accessing OCI.

The release notes point to German locale browsers, but I recall using this on a France locale'd browser as well and seeing success.

If on 7.3.2 and you still see this, I think opening a case would be the quickest way forward.

[gmilazzoitag]

Hi,

well, but, waiting for an upgrade to 7.3.2 in the meantime is there some tip for 7.3.1SP2?
I agree with you that the issue on german/fremch browser could be the same for the italian. All use DD/MM/YYYY (only the US and Canada still continue to use MM/DD...and pounds, gallons, miles, feet and so on )


PS) I did not found IFR-3654 in the 7.3.2 release notes.

[hoffman]

In terms of workarounds, have you tried moving the client browser locale to US en? I *think* that should work (you'll be working in US-style dates for the time being though). Upgrade to v732 is the only server-side action I know of that will fix this.

[gmilazzoitag]

Hi,

I can test only on the 7.3.0 of the LOD but I've passed the info to the customer running 7.3.1SP2.
In the LOD I've noted that also changing the date format from Control Panel nothing change but actually I did not get any error. As I've written whatever the date format or the Chrome locale is, I can choose a date from calendar popup and this is regularly converted in english format (i.e. I choose dec, 28 and it's printed 12/28).
The customer instead choosing dec. 28 get a 28/12 causing the error.
I think that this can be considered a minor issue and an upgrade to 7.3.2 can wait to be scheduled.

Regards,