We're having an issue with a custom-build form date input component. The component formats Javascript date objects into user-friendly strings for user display/input, i.e. "5 May 2019", and then parses these strings back into JS Date objects when user saves before saving to backend.
Both formatting from JS Date object into user-friendly strings and parsing from user-friendly strings into JS Date object are performed using Aura Localisation Service to ensure proper localisation based on the User viewing the component.
We're now experiencing what appears to be a bug with some specific locales, and we are not sure how to approach the issue.
The issue is that the Aura localization service is unable to properly parse back into JS Date object some user-friendly date strings that are result of formatDate calls. See this screenshot for practical example (language is German, temp1 is $A.localizationService):
STEP 1: create Date object referencing 5th December 2019
STEP 2: format the Date object into user-friendly string using formatDate
STEP 3: failed attempt to parse user-friendly date into JS Object - result is wrong (date is January not December)
STEP 4: failed attempt to parse user-friendly date without passing format in - result is null
STEP 5: if a dot (.) is added to the month parse is successful
It is my impression that the localized month names expected by the "parseDateTime" function should be the same that the "formatDate" function spits out, and I consider any different behavior to be broken. It is a really painful issue for us to solve, and it's non-obvious what is the correct resolution path to take... so here's my ask:
- Has anybody in the community encountered the same problem before?
- Is there something you think we might be doing better/differently to avoid this problem based on your experience with Aura localizationService?
- Could this be considered a bug worth of being reported to SFDC team?
