LLeapGrove
AIコーディングワークスペース

グレゴリオ暦の閏年規則

1年から9999年までのグレゴリオ暦の年を閏年と平年に分類してください。

● ● ●LeapGrove●
ワークフロー · グレゴリオ暦の閏年規則 ×
def is_leap_year(year):
    if type(year) is not int or not 1 <= year <= 9999:
        raise ValueError("year.range")
    return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
✳グレゴリオ暦の閏年規則
✓ 変更内容適用前に確認 ↗
ワークスペースのイメージ
モデル
OpenAI互換またはAnthropicのエンドポイントを、ベースURLと必要なAPIキーで設定し、接続をテストします。ローカルのモデルサーバーは起動が必要です。リモートツールは別途データを送信する場合があります。
プロジェクト
1900年、2000年、範囲の両端を確認し、ゼロ年、小数、真偽値を拒否してください。
適用前に確認
実際の動作を期待する結果と比較します。検証に失敗した場合は、次の変更を加える前に原因を調べてください。
ワークフロー

グレゴリオ暦の閏年規則

ワークフロー ↗
ワークフロー
def is_leap_year(year):
    if type(year) is not int or not 1 <= year <= 9999:
        raise ValueError("year.range")
    return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
AIコーディングワークスペース

コードを変える前に暦の前提を書き出す

日付のルールは、例外的な年や対応範囲外の値に出会うまでは自明に見えがちです。LeapGroveは、その前提を開発の会話に持ち込めるWindows用AIコーディング作業環境です。該当するプロジェクトフォルダーを開き、必要な暦の動作を示して、入力値が日付処理コードに届く経路を調べるようアシスタントに依頼しましょう。

年の範囲を限定したうるう年関数は、検討できる一例です。フォームやインポート経路に合わせる前に、対応する年、拒否する型、呼び出し元のレビューを頼めます。対象の暦法を明示し、入力検証と暦のルールそのものを区別してください。なじみのある公式を利用状況の確認なしに信頼するのではなく、評価可能なソフトウェア変更として提案を扱えます。

対応するOpenAI互換またはAnthropicのエンドポイントを使い、必要な認証情報を渡して、利用可能な無検閲AIモデルを選択できます。モデルのポリシー、ツールへのアクセス、コンテキスト容量は接続先に依存します。差分を確認し、関連するプロジェクトのチェックを実行して、通常の年と仕様に含まれる例外的なケースをテストしましょう。ローカルのエンドポイントには別途稼働中のモデルサーバーが必要で、接続されたすべてのツールがローカルになるわけではありません。

先に決めておきたい暦の要件

なぜ依頼に対応する年の範囲を書くのですか?

アプリケーションが、汎用の暦ライブラリより狭い範囲に意図的に対応している場合があります。境界を指定し、変更前に呼び出し元を確認してください。うるう年の計算自体が同じでも、受け付ける年を増やすと後続の動作は変わり得ます。

数字の文字列を有効な年として扱うべきですか?

アプリケーション内のどこで変換するかを決めてください。フォームは厳密な補助関数を呼ぶ前に文字列を解析し、内部APIは文字列を拒否することもあります。この役割分担を保つ提案を求め、合意した動作を明示的にテストしましょう。

正しいうるう年補助関数があれば日付全体を検証できますか?

いいえ。月の日数、日の範囲、アプリケーションの暦の前提には、それぞれの処理が必要です。補助関数の責任範囲を明確にし、他のチェックと組み合わせるコードを確認してから入力が有効か判断してください。

依頼した日付変更をレビュー担当者はどう確認できますか?

仕様に関係する境界の年を含め、受け付ける例と拒否する例を具体的に示します。補助関数と呼び出し元をレビューし、実際の入力経路でそれらを実行してください。単独の計算ではフォームやインポートの動作は検証できません。

Windows版をダウンロード ↗

LeapGrove · 更新日 2026-10-25