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):

enter image description here

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?
  • A support case was submitted and it's now pending 3rd tier review. I'll update the question when I'll receive feedback.
    – MLucci
    Nov 26, 2019 at 10:24

1 Answer 1


A new platform bug W-7059094 has been created: "$A.localizationService.parseDateTime returns incorrect date for language Deutsch"

The suggested workaround is not applicable in our case because our app doesn't use a static dateTimeFormat for everyone that we can modify/control, but rather uses the dateTimeFormat coming from $Locale user context data.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .