Sp-dev-fx-webparts: React ListForm webpart - cannot get past Date error in Edge/Explorer

Created on 15 Jun 2018  路  7Comments  路  Source: pnp/sp-dev-fx-webparts

Category

  • [ ] Question
  • [x] Bug
  • [ ] Enhancement

Expected or Desired Behavior

Once the webpart is deployed to sharepoint and connect to a list with a date time field, form should submit.

Observed Behavior

I have neither the date in the spfx code required, nor the date column in the list. Everytime i pick a date with the date picker it just keeps doing an error loop, observed only in Edge and IE, Chrome passes it right through.

image

Steps to Reproduce

npm install
gulp
gulp build --ship
gulp package-solution --ship

attach to a list that has a date time column

Thank you so much
Doug

Thanks for your contribution! Sharing is caring.

Most helpful comment

I found the problem.
The SPFieldDateEdit uses the DateFormField component, which renders the Fabric UI DatePicker.

It supplies the formatDate property like this:

    formatDate={ (date: Date) => (typeof date.toLocaleDateString === 'function') ? date.toLocaleDateString(this.props.locale) : '' }

Meaning it will display a date based on the browser's language setting.
Let's say your browser is set up to display 'dd/MM/yyyy', resulting in '19/06/2018' for June 19th.

The DateFormField component also supplies the parseDateFromString property to the DatePicker, to parse the user's input back into a date, like this:

    parseDateFromString={ (dateStr: string) => { return new Date( Date.parse(dateStr) ); } }

Now the problem is, that Date.parse does not parse by local rules. It expects some standard format.
All goes fine it your browser happens to be setup for 'MM/dd/yyyy', but not differently.

In other words - the roundtrip does not work.
You need to adjust the parsing method to take in what the formatting method displays and the user will edit. You can do so for example by using the moment library and specifying a format when parsing it, e.g. like this:

    parseDateFromString={ (dateStr: string) => { return moment(dateStr, moment.localeData(this.props.locale).longDateFormat('L')).toDate(); } }
    formatDate={ (date: Date) => moment(date).format(moment.localeData(this.props.locale).longDateFormat('L')) }

That should do the trick no matter what the browser setting is.

Or, if you want it real easy, comment out the two lines or remove them altogether, then the DatePicker will display in (and accept input in) a local format like 'Thu Jun 14 2018'.

All 7 comments

Sounds like a language issue (mismatch of web locale and browser/system language).
The SPFieldDateEdit uses the DateFormField which uses the DatePicker and supplies custom parsing methods which parse the date according to local browser locale settings, which might conflict with the internal data format, or on the roundtrip when a newly selected date is passed back to the parent component. One would have to analyze this, or reimplement it, certainly some bug in there.

I found the problem.
The SPFieldDateEdit uses the DateFormField component, which renders the Fabric UI DatePicker.

It supplies the formatDate property like this:

    formatDate={ (date: Date) => (typeof date.toLocaleDateString === 'function') ? date.toLocaleDateString(this.props.locale) : '' }

Meaning it will display a date based on the browser's language setting.
Let's say your browser is set up to display 'dd/MM/yyyy', resulting in '19/06/2018' for June 19th.

The DateFormField component also supplies the parseDateFromString property to the DatePicker, to parse the user's input back into a date, like this:

    parseDateFromString={ (dateStr: string) => { return new Date( Date.parse(dateStr) ); } }

Now the problem is, that Date.parse does not parse by local rules. It expects some standard format.
All goes fine it your browser happens to be setup for 'MM/dd/yyyy', but not differently.

In other words - the roundtrip does not work.
You need to adjust the parsing method to take in what the formatting method displays and the user will edit. You can do so for example by using the moment library and specifying a format when parsing it, e.g. like this:

    parseDateFromString={ (dateStr: string) => { return moment(dateStr, moment.localeData(this.props.locale).longDateFormat('L')).toDate(); } }
    formatDate={ (date: Date) => moment(date).format(moment.localeData(this.props.locale).longDateFormat('L')) }

That should do the trick no matter what the browser setting is.

Or, if you want it real easy, comment out the two lines or remove them altogether, then the DatePicker will display in (and accept input in) a local format like 'Thu Jun 14 2018'.

Thank you for finding this Matthias! So i tried both lines of your code and even tried commenting them out. Works beautifully on Chrome and Firefox, but Edge throws the error still. I even went through and changed the date/time format in windows settings, but Edge just doesnt like it. Unfortunately 98% of my users are on Edge. Any thoughts there?

Can you describe when exactly the error occurs? At saving or after entering a value? Maybe I am describing a different case. I was merely guessing it is language-dependent, since it works in one browser and not the other. Can you reproduce the problem by varying the primary language in the language settings of Firefox? I don't have the problem in Edge, so something must be different on your system. Which language is your Windows?

It occurs on the Save.You can enter any date and it works as expected,but when you click save on Edge it throws the error right beneath the field. The language for the computer and browser is en-US

I have just tried the original, commented out lines and added your lines @frevds to no avail. My locale is UK so everything is set to dd/mm/yyyy. When I select a date from the picker with any of the above solutions it first displays mm/dd/yyyy then upon clicking off the field it swaps over to dd/mm/yy.

This is all good up until you try any day beyond the 12th, the field will not populate at all.

Thanks in advance for any help.

@dmcrock did you ever resolve this issue?

I'll go ahead and close it as there has been no activities here for a while. Feel free to open a new issue if you're still having troubles.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

joshburns49 picture joshburns49  路  3Comments

russgove picture russgove  路  4Comments

PathToSharePoint picture PathToSharePoint  路  4Comments

Abiman194 picture Abiman194  路  4Comments

Abiman194 picture Abiman194  路  3Comments