A change in the interpretation of Date/Time strings (which originates from Java under the hood) will be enforced in all Salesforce orgs in mid-January 2022. (Find details here: https://help.salesforce.com/s/articleView?language=en_US&id=release-notes.rn_forcecom_globalization_enable_icu_cruc.htm&type=5&release=222

Given you have a Large Managed Package with hundreds of Custom Objects and thousands of Fields, Formulas and Validations thousands of classes and Flows that potentially create, manipulate or interpret Date/Time values in a soon invalid way.

  1. How would you find this out in an effective investigation?
  2. What would be your steps?
  3. Which searches on your Git repo (containing your app) would reveal risky areas?

1 Answer 1


There's been some updates so it's best to look at the documentation outside of the previous release notes which can be outdated.

Go Global with New International Locale Formats is the parent page and mentions that enforcement is now for all orgs in Spring '23. I'd also point out that newer orgs since Winter '20 have been using this format/update and any org can update if they choose.

Off that document are some helpful docs that cover your questions and where the below information is coming from:

There's a lot of information there, but it's good to understand what data can change based on locale which this updates affects

  • Address
  • Currency
  • Date
  • DateTime
  • Integer
  • Name
  • Time

So for searching problematic points of your app (or areas to focus testing on), it'd be best to look for situations where you're interacting with those formats/fields in non-standard ways

This won't be an exhaustive list (though feel free to add suggestions) but searching should revolve around areas of concerns

  • .format()
  • .parse(
  • Date.valueOf() or .valueOf()
  • .formatLong()
  • $Locale
  • LWCs with @salesforce/i18n
  • Pattern or Matcher might show any regex you might be doing against certain data formats that are changing
  • List view and report hard-coded filters AM</value>, PM</value>, <startDate>

Those components that return should be checked that there's no custom parsing or expectation of formats that locale may interfere with. The focus for code is on methods that return locale-based results - a couple examples from the docs:

  • format() in Date, DateTime, and Integer returns formatting based on the user locale - if you explicitly expect a certain format, make sure to appropriately set it: ex. .format('h:mm a'). Searching for the method name with no argument should catch those occurrences.
  • Use standard methods when parsing information from those affected data types. ex. Use .month(). This applies to formula fields and declarative (ex. MONTH()).
  • Handle integers and currency values as unformatted until you must format them

In short, your steps might look like the following:

  1. Update apex and VF to API 45 or later
  2. Identify areas of app that rely on affected data (specifically using non-standard methods)
  3. Enable and test
  • Really helpful and hands-on. Thank you Kris! Dec 17, 2021 at 9:09
  • 1
    Maybe you want to add Date.valueOf() to your answers list of areas of concern. When we store Locale specific Data as serialized Strings in external databases or even Salesforce records and deserialize it back after the ICU change the Code will break. Dec 20, 2021 at 10:27
  • 1
    Good call, edited. Feel free to make edits directly to the answer as you go through it and uncover more. Dec 20, 2021 at 14:39

You must log in to answer this question.

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