ICU ロケール形式の有効化の準備


+ [JDK ロケール形式の廃止と ICU ロケール形式の有効化リリース更新でのエラー通知](https://qiita.com/Keiji_otsubo/items/54f46b5f3d31198bbd82)

### レポートにも影響する

+ [レポートをエクスポートすると￥マークがJPYに変わる](https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000PW2vS0AT)


-----------------
Salesforceからの重要なお知らせ。なんか不吉な予感だ。

ちょうどこれに関する質問もあった

[Ways to query items using a hard-coded date in an org?](https://trailblazers.salesforce.com/answers?id=9064S000000DwrfQAC)

ヘルプ

[Go Global with New International Locale Formats](https://help.salesforce.com/articleView?id=sf.icu_migration_overview.htm&type=5)

* Spring ’22 リリースより、Salesforce では International Components for Unicode (ICU) ロケール形式が必須になります。
* ご利用いただいている組織では、まだ ICU 形式を採用されていないようです。
* ICU を採用することで、日時や通貨など、すべてのロケールデータのパターンと形式に一貫性を持たせることができます。

https://help.salesforce.com/articleView?id=release-notes.rn_forcecom_globalization_enable_icu.htm&type=5&release=230&utm_source=techcomms&utm_medium=email&utm_campaign=FY22_Core

組織で使用されているロケールと各ロケールのユーザ数を検索します。
```
SELECT toLabel(LocaleSidKey) LocaleName, LocaleSidKey, Count(id) UserCount FROM User where IsActive=true GROUP BY LocaleSidKey
```
# 変更点

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/069c9cd7-46f3-6acb-cb4d-139878d6726d.png)
で、何が問題になるのか？

### 2021/06/16の考察
Date- Long : 現在2021/06/16 -->移行後 2021年6月16 になるような書き方。

ちょっと、困ったのが 月の桁数が変わっている。　もし年月日を桁数で抜き取っている場合は問題になりそうな気がします。こういうところを重点的にチェックした方がよさそうな気がしています。

### 2025/01/07の考察

+ [What is an example of a situation that explains why this change affects me and how I would resolve it?](https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX000000P8TH)

:::note
Downloading reports w/date-time fields seems like the only real impact to users beyond display. The comma means that Excel formats the date/time vals as text so your users will need to remove the comma to sort chronologically.

日付/時刻フィールドを含むレポートをダウンロードすることは、表示以外ではユーザーにとって唯一の実際の影響のようです。コンマは、Excel が日付/時刻値をテキストとしてフォーマットすることを意味するため、ユーザーは時系列で並べ替えるためにコンマを削除する必要があります。
:::


# 対策の着眼点

The ICU format change doesn't necessarily mean things will break - only that certain field formats may change. Only functionality that was built to rely on particular formats would break, like if you have something that gets the time portion from a date-time text. 


ICU形式の変更は、必ずしも問題が発生することを意味するわけではありません。特定のフィールド形式が変更される可能性があるだけです。日時テキストから時間部分を取得するものがある場合のように、特定の形式に依存するように構築された機能のみが機能しなくなります。

[How to Adopt the New Locale Formats: Evaluate the impact to your org](https://trailblazers.salesforce.com/answers?id=9064S000000kJ35)



+ [「英語 (カナダ) [en_CA] ロケールの ICU 形式を有効にする」必要があるのはなぜですか?](https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX000000mzoE0AQ)

:::note
+ カナダ (英語) の場所にユーザーがいない場合は、これを有効にする必要はありません。

「ロケールは、日付と時刻、ユーザー名、アドレス、および数字のカンマとピリオドの表示形式を決定します。カレンダーの週の開始曜日はロケールごとに異なります。」

+ このロケール形式を必要とするユーザーがいる場合でも、 Salesforce が組織で自動的に有効にする前に ICU 形式を有効にする場合にのみ、これを手動で有効にする必要があります。
:::

+ [私たちは何をする必要がありますか?](https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000J6alw)




# レポート、数式、入力規則、その他の自動ワークフローの検索条件を確認する
日付、数値、または通貨ベースの検索条件が新しい形式で適切に機能することを確認します。よく発生する問題として次のようなものがあります。

* 検索条件で「ハードコード化」された日時値を使用している場合、その値が新しい形式に適合しない限り、検索条件は適切に機能しません。
* 新しい形式には、新たにカンマが追加されているものがあります。カンマは検索条件の区切りに使用されるため、これによって検索条件が誤動作する可能性があります。

# 項目のルックアップ検索条件を確認する

オブジェクトの項目に対して定義した検索条件が新しい形式で機能することを確認します。日付、時刻、数値を使用している検索条件は、変更が必要になる場合があります。

# Apex コードを確認する
Apex コードをテストして、新しい形式で機能することを確認します。テスト時には、現在のロケールに基づいて形式を返すメソッドに重点を置きます。たとえば、Date.format()、Date.parse()、DateTime.format()、DateTime.parse()、DateTime.formatLong() などのメソッドです。

次のコードブロックを考えてみます。

```
Datetime myDT = Datetime.now();
String myDate = myDT.format('h:mm a');
```

この例は、文字列の引数 'h:mm a' を format 関数に渡すため、dateTime は、ロケールに関係なく指定された形式 'h:mm a' に従って形式設定されます。後続のコードが特定の形式を期待する場合、日付、時刻、通貨の形式設定にはこの方法を使用することをお勧めします。

+ [ICUローカルフォーマット](https://trailhead.salesforce.com/ja/trailblazer-community/feed/0D54S00000G3zoV)

Apexは、新しいロケール形式を問題なく処理できます。ただし、ベストプラクティスは、ロケールに依存しないApexメソッドを使用することです。

[Use Locale-Neutral Methods in Code](https://help.salesforce.com/s/articleView?id=sf.admin_locales_code_methods.htm&type=5)

 **format 関数に引数を渡さないと、ユーザのロケールによって dateTime 形式が決まります。** この方法は、ユーザに表示する情報を作成する場合に便利です。

やっぱりすごい。私が師匠と密かに思っているイギリスの方の回答
やっぱり、format関数は要チェックみたい。

[Do ICU Locale Formats apply to Web Services API](https://trailblazers.salesforce.com/answers?id=9064S000000kILHQA2)


# Aura コンポーネントを確認する

 **$Locale**  は、Salesforce Platform から取得された形式を使用します。これらの属性を十分にテストします。

# すべてのインストール済みパッケージに ICU 形式との互換性があることをパッケージプロバイダに確認します。
しかしながら、Salesforce Labsはどこに聞けばいいのかという質問がちらほらあります。さすがはお師匠さん、いい答えを教えてくれました。

What I'd recommend doing is to just create a sandbox, activate ICU, and try it out yourself!


# 保存時は？

+ [How will records be updated to the ICU Locale?](https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007KYceT)

:::note
 locales are not persisted/stored in the database with records. Users have a locale and the UI dynamically formats the data for the active user. So there is no change to your data when you enabled ICU Locale Formats.


ロケールはレコードとともにデータベースに永続化/保存されません。ユーザーにはロケールがあり、UI はアクティブなユーザーのデータを動的にフォーマットします。したがって、ICU ロケール形式を有効にしてもデータは変更されません
:::

# 未解決

+ [It dosen't work in Japanese locale??](https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000JfS7Q)

# 新しい組織の「リリース更新」に「ICU ロケール形式を有効にする」が引き続き表示される

+ [新しい組織の「リリース更新」に「ICU ロケール形式を有効にする」が引き続き表示される](https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX000000O1wt)

Winter '20 以降に作成された本番組織では、ICU ロケール形式がデフォルトで有効になっています。それ以降に作成または更新されたサンドボックスには、ソース組織と同じ設定が使用されています。

このリリース更新の適用は、何度か延期されています。Winter '25 リリース更新で発表されたように、Salesforce は Spring '24 以降、JDK ロケール形式の代わりに ICU ロケール形式を段階的に有効化してきました。まだ JDK ロケール形式を使用している残りの組織は、Spring '25 で ICU ロケール形式が自動的に有効化されます。影響を受ける組織の管理者には、11 月初旬にこのイベントを通知するメール通信を送信する予定です。