Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    SmartGWTEE 12.0p - "Must be a date" error on datetime fields after calling "autoDetectFormats"

    isc Version: v12.0p_2019-01-21/Enterprise Deployment
    GWT Version: 2.7.0
    Browser: Chrome Version 71.0.3578.98 (Official Build) (64-bit)
    OS: Windows 10
    SuperDevMode

    Hello, I am seeing a problem when attempting to save 12-hour DateTime items after using DateUtil.autoDetectFormats() when the locale is "en". Below are the steps to reproduce this by modifying the built-in-ds sample to include a datetime field.

    Step 1: Convert supplyItem.nextShipment to datetime
    a. In war/WEB-INF/db/hsqldb/isomorphic.script, replace all occurences of "NEXTSHIPMENT DATE" with "NEXTSHIPMENT TIMESTAMP"
    b. In war/ds/supplyItem.ds.xml, change type of nextShipment field from "date" to "datetime"
    c. Create a new record and select a Next Shipment date using the date picker. The date is in 24-hour format and saves without errors.

    Click image for larger version  Name:	nextShipment_1.png Views:	1 Size:	70.7 KB ID:	256675

    Step 2: Set up "en" GWT locale, and detect date format automatically
    a. At the bottom of BuiltInDS.gwt.xml, add these lines:
    Code:
    <extend-property name="locale" values="en"/>
            <set-property-fallback name="locale" value="en"/>
    b. In BuiltInDS.java, add this line to the beginning of onModuleLoad():
    Code:
    DateUtil.autoDetectFormats();
    c. Create a new record and select a Next Shipment date using the date picker. The date is in 12-hour format, and gives an error of "Must be a date" when attempting to save. No javascript errors are present in the console and no network traffic is observed (aside from the loading of the error icon).

    Click image for larger version  Name:	nextShipment_2.png Views:	1 Size:	72.0 KB ID:	256676

    Any suggestions you have would be appreciated! It seems like it nothing I did should prevent the field from saving, but I might be missing a step that needs to be happen after using autoDetectFormats(), I'm not sure.

    (After a quick peek in the debug modules, it looks like isc.DateUtil._splitDateString() will only accept lowercase "am/pm", while the field is formatted with uppercase. Is there some additional configuration I need to do to the datetime field to ensure that it uses a compatible format?)

    Thank you!
    Last edited by jbrasee_iqs; 30 Jan 2019, 10:06.

    #2
    Thanks for the report - we've fixed the regex you mentioned to support a case-insensitive am/pm string - you should see things working as you expect in builds dated February 1 and later.

    Comment


      #3
      Just updated to v12.0p_2019-02-06/Enterprise Deployment and confirmed that the problem is resolved. Thanks!

      Comment

      Working...
      X