2019/02/06更新
ファイルメーカー社から正式なアナウンスがありました。
というわけで、下記スケジュールになります。
安全に新元号に対応するには、FileMaker Pro Advanced のアップデートを待つか、この機会に元号での管理を見直してはどうでしょうか。
2019年5月1日から新元号になる予定ですが、元号名は発表されていません。
FileMaker プラットフォームの新元号対応ですが、サポート中のバージョンはアップデートが出るそうです。
サポート中のバージョンは下記から確認できます。
サポート対象製品
サポート中のバージョンであれば、まず安心ですね。
ですが、もし下記に当てはまる場合を考えてみたいと思います。
元号発表のタイミングがギリギリになって当日に間に合わない
サポート外のバージョンを使っている
そもそも、新元号による計算が狂うような致命的な問題は起こりません。FileMaker Pro は内部的には0001年1月1日からの日数として管理しています。
起こる問題：見た目
（新元号が未来だとすると・・・）
※元号の選定には省略した時のアルファベットも考慮されているので、"明治=M"と被る"未来=M"は実際には無いです
正：2019年5月1日→未来元年5月1日
誤：2019年5月1日→平成31年5月1日
となってしまいます。
FileMaker Pro 13 以降であれば隠す設定で上手いこと平成の部分に重ねれば対応できます。テキストの背景色と帳票の背景色を合わしておくのがポイントです。
それより前のバージョンの場合は、計算フィールドと条件付き書式で同様のことが可能です。
条件付き書式も使えないバージョンの場合は・・・日付を計算フィールドにして表示を分岐させるか、この機会にバージョンアップしましょう。
起こる問題：入力
日付フィールドでH31/5/1と入力すると自動的に2019/5/1と変換されます。
これはスクリプトトリガや計算値自動入力の設定で対応出来ます。
簡単に書くと
Substitute ( Self ; "H31" ; "2019" )
という様に置き換えてやれば良いのです。
（実際には翌年も考慮しないといけないので、この計算式ではダメです）
また、元号で入力するケースは生年月日の様な過去の日付が多いはずです。新元号で入力する状況は多くはないはずなので、ここまで気を使う必要性は低いでしょう。
長々と書きましたが、下手に既存のシステムに手を加えてバグを出すよりはFileMaker Pro のアップデートを待った方が安全でしょう。
漠然と新元号の対応に不安を感じる人は、具体的に何が困るか一度考えてみてはどうでしょうか。
多くは印刷物がかっこわるい、、、ぐらいでしょう。