導入: なぜ今「getYear」を知る必要があるのか
JavaScriptで日付を扱う際、レガシーなコードを保守していると「getYear」というメソッドに出会うことがあります。しかし、結論から述べると、getYearは現在「非推奨（Deprecated）」であり、絶対に使用してはならないメソッドです。このメソッドは、2000年問題（Y2K）に関連する仕様上の欠陥を抱えており、意図しないバグを引き起こす原因となります。本記事では、なぜgetYearが危険なのか、そして現代のフロントエンド開発でどのような代替手段を用いるべきかを解説します。
基礎知識: getYearの仕様と「2000年問題」
JavaScriptのDateオブジェクトには、年を取得するためのメソッドが複数存在します。
getYearは「1900年からの経過年数」を返すように設計されています。例えば、1998年であれば「98」、2024年であれば「124」という値を返します。
この仕様の何が問題かというと、「2桁の年号」を返す場合と「3桁以上の年号」を返す場合が混在する点です。特に1900年代のコードで「下2桁」を前提としていた処理が、2000年以降に「100以上」の値を返すようになったことで、多くのシステムで不具合が発生しました。これが、ECMAScript標準から排除された経緯です。
実装/解決策: 正しい年取得の方法
現在の日付取得には、「getFullYear」を使用するのが標準ルールです。getFullYearは、西暦を4桁（例：2024）で正確に返すため、getYearのような曖昧さがありません。
サンプルプログラム: 正しい実装と注意点
以下は、getYearの危険性と、getFullYearによる安全な実装の比較コードです。
// 現在の日時を取得
const now = new Date();
// 【非推奨】getYearの使用例（2024年の場合、124が返る）
const badYear = now.getYear();
console.log("getYearの結果:", badYear); // 124
// 【推奨】getFullYearの使用例（2024年の場合、2024が返る）
const goodYear = now.getFullYear();
console.log("getFullYearの結果:", goodYear); // 2024
// 実務でよくある「西暦の下2桁が必要」な場合の安全な処理
// 文字列操作を行うことで、予期せぬ数値変化を防ぐ
const shortYear = String(goodYear).slice(-2);
console.log("下2桁の取得:", shortYear); // "24"
応用・注意点: 現場で役立つアドバイス
実務において「日付操作」は非常にバグを生みやすい領域です。以下の点に注意してください。
1. ライブラリの活用を検討する
ネイティブのDateオブジェクトは非常に癖が強く、タイムゾーンの計算やフォーマット変換が困難です。プロジェクトの規模が大きい場合は、date-fnsやDay.jsといった軽量な日付ライブラリの導入を強く推奨します。これらを使うことで、getYearのようなレガシーな仕様に悩まされることはなくなります。
2. ESLintの設定
コードベース内にgetYearが残らないよう、ESLintのルール（no-restricted-properties）を設定して、ビルド時に警告を出すようにしましょう。
3. 2桁表記の罠
UI上で「24/05/20」のような表記を行う際、単なる数値計算（- 1900など）を行うのは危険です。必ず文字列として扱い、末尾2文字を切り出す等の方法を採用することで、100年単位のバグを回避できます。
現代のフロントエンド開発においては、「動くコード」を書くこと以上に「将来的にバグを生まないコード」を書くことが重要です。まずはプロジェクト内のgetYearをすべてgetFullYearに置き換えることから始めてみてください。