導入
JavaScriptのDateオブジェクトを操作する際、レガシーなメソッドである「setYear」に遭遇したことはありませんか？一見、日付の年数を設定する便利なメソッドに見えますが、実は現代のフロントエンド開発において「避けるべき」非推奨のAPIです。本記事では、なぜsetYearの使用を避けるべきなのか、そして実務でどのように代替すべきかを解説します。
基礎知識
Date.prototype.setYearは、対象のDateオブジェクトの年を設定するためのメソッドです。しかし、このメソッドには「西暦1900年問題」とも言える独特な挙動があります。具体的には、引数に0から99の数値を渡すと、1900年にその数値を加算した年（例: 95なら1995年）として解釈されます。この仕様は直感的ではなく、特に2000年以降のシステム開発において深刻なバグを引き起こす原因となります。現在、ECMAScript標準でも「非推奨（deprecated）」として扱われています。
実装/解決策
実務では、setYearの代わりに「setFullYear」を使用するのが正解です。setFullYearは、4桁の西暦を正確に受け付けるため、曖昧さがなく、現代のアプリケーション開発における標準的なプラクティスです。
サンプルプログラム
以下に、setYearの危険な挙動と、推奨されるsetFullYearの安全な実装例を比較します。
// 現在の日付を取得
const date = new Date();
// 【非推奨】setYearの使用例
// 95を指定すると1995年になってしまう
date.setYear(95);
console.log("setYear(95)の結果:", date.getFullYear()); // 1995 と表示される
// 【推奨】setFullYearの使用例
// 4桁で指定することで意図した通りに設定できる
const safeDate = new Date();
safeDate.setFullYear(2025);
console.log("setFullYear(2025)の結果:", safeDate.getFullYear()); // 2025 と表示される
// 実務での応用例：特定の年へ更新する関数
function updateYear(dateObj, year) {
// 不正な値のチェックを行うとより堅牢になります
if (typeof year !== 'number' || year < 0) {
throw new Error("有効な年数を指定してください");
}
const newDate = new Date(dateObj);
newDate.setFullYear(year);
return newDate;
}
応用・注意点
現場で既存コードを修正する際は、単にメソッドを置き換えるだけでなく、以下の点に注意してください。
1. タイムゾーンの影響
Dateオブジェクトは実行環境のローカル時間に依存します。サーバーとクライアント間で日付をやり取りする場合は、UTCベースで操作できる「getUTCFullYear」や「setUTCFullYear」の使用を検討してください。
2. Dateライブラリの検討
Dateオブジェクトの複雑な操作に疲弊している場合は、現代のプロジェクトでは「date-fns」や「Day.js」といった軽量ライブラリの利用を強く推奨します。これらを使用することで、今回のようなAPIの仕様によるハマりどころを回避し、コードの可読性を大幅に向上させることができます。
3. 既存コードの保守
もし古いプロジェクトでsetYearが多用されている場合、いきなりすべてを書き換えると副作用が生じる可能性があります。まずはユニットテストを作成し、挙動が変化しないことを確認してから置換を行うようにしましょう。