WAGBY11 MANUAL / 03
日付・時刻・日時を扱う
日付だけ、時刻だけ、日付と時刻の組み合わせを用途に応じて使い分けます。
最終更新日:
1. このページで伝える機能
日付だけを管理するときはdate、時刻だけならtime、日付と時刻を一緒に管理するときはdatetimeを使えます。
この例では「受付日」「開始時刻」「受付日時」を別の項目として用意し、それぞれの値を保存・表示します。
2. Wagby11で実現できること
2.1 必要な情報に合わせて入力する
| 項目 | 入力する内容 | 保存した例 |
|---|---|---|
| 受付日 | 年・月・日 | 2026/10/29 |
| 開始時刻 | 時・分 | 09:30 |
| 受付日時 | 年・月・日と時・分 | 2026/10/29 10:15 |
登録・更新画面では「日付・時刻」タブを開きます。受付日は日付欄、開始時刻は時刻欄、受付日時は日付と時・分の欄で入力します。日付欄にはカレンダーを開くボタンもあります。
2.2 保存後の値を用途に合う形式で表示する
詳細画面では、日付だけ、時刻だけ、日付と時刻の組み合わせとして確認できます。開始時刻は秒を表示せず、時・分で表示しています。

本日や現在日時を自動で入れたい場合は初期値、開始日と終了日の関係を確認したい場合は入力チェックで設定できます。
2.3 タイムゾーンの考え方
タイムゾーンは、その地域で使う時刻の基準です。日本の標準時はUTC(協定世界時)より9時間進んでいます。この差をUTCオフセットと呼び、+09:00と表します。例えば、日本の2026年10月29日10時15分は、UTCでは同じ日の1時15分です。
| 型 | 保持する情報と例 | 使い分け |
|---|---|---|
日付(date) | 年月日。例:2026-10-29 | 生年月日や納期など。時刻やUTCオフセットを持ちません。 |
時刻(time) | 時分秒。例:09:30 | 毎日の始業時刻など。日付やUTCオフセットを持ちません。 |
日時(datetime) | 年月日と時分秒。例:2026-10-29 10:15 | 通常の業務日時。UTCオフセットを持たないため、「日本時間の受付日時」のように業務上の時刻の基準を決めて使います。 |
UTCオフセット付き日時(offsetdatetime) | 年月日、時分秒、UTCとの差。例:2026-10-29T10:15:00+09:00 | 海外システムとの連携など、どの時差の日時かも保持したい場合に使います。 |
datetimeの「10:15」だけでは、日本の10時15分か、別の地域の10時15分かは判別できません。利用者が海外にいる場合も、その値が自動的に現地時刻へ換算されることを前提にせず、「日本時間で入力・表示する」などの運用をAIへ伝えます。
offsetdatetimeは、REST APIから2026-10-29T10:15:00+09:00を渡すと、そのUTCオフセットを保持します。業務データを一律にUTCへ置き換えて保存する設定ではありません。Web UIでは通常の日時と同じ入力欄を使い、登録時には環境のタイムゾーンに対応するオフセットを付けます。利用者がオフセットを選ぶ欄はないため、異なるオフセットを明示して登録する場合はREST APIを使います。
3. AIへの指示例
最小限の指示例
受付情報に受付日・開始時刻・受付日時を入力できるようにしてください。日付だけか日時も必要か、秒を扱うか、表示書式はどうするかなどをAIが類推して補います。意味が決まっている場合は、各項目に必要な情報を明確に伝えます。海外でも利用する場合は、入力・表示する時刻の基準や、時差を含めて保持する必要があるかも伝えます。
より詳細な指示例
受付情報モデル(Entry)で、次の項目を標準機能で用意してください。
既存の主キー、権限、項目、データを保持し、必要なguide・referenceを確認してください。
・受付日は日付型で、年・月・日を入力できるようにしてください。
・開始時刻は時刻型とし、時・分を入力して、詳細画面でも時・分で表示してください。
・受付日時は日本時間で扱う日時型とし、日付と時・分を入力できるようにしてください。
・海外の利用者も、受付日時は日本時間で入力・表示する運用にしてください。
・受付日の表示はyyyy/MM/dd、受付日時はyyyy/MM/dd HH:mmにしてください。
・3項目とも任意入力にしてください。
・受付日2026/10/29、開始時刻09:30、受付日時2026/10/29 10:15を保存して確認してください。
モデルがまだない場合は、自動採番の受付IDを主キーとし、既存のG_ADMINロールに登録・参照・更新・削除を許可してください。
「受付管理」に「受付情報検索」の入口を用意し、一般利用者向け操作マニュアルも追加・更新してください。
設計情報の検証・コード生成・起動を行い、入力した値が保存後も確認できることを検証してください。時差も保持したい場合の追加の指示例
海外システムから受け付けた日時など、UTCオフセットが必要な項目は、通常の受付日時とは別に指示します。
外部受付日時には、連携元から届いた日時とUTCオフセットを保持してください。
REST APIで2026-10-29T10:15:00+09:00を受け付け、読み出しても同じ日時とオフセットになることを確認してください。
画面の日時入力欄ではオフセットを選べないことを踏まえて、登録方法と画面上の表示書式を提案してください。4. 編集されるAppSchemaの例
項目の型と表示書式の抜粋です。
entity:
attributes:
- { name: 受付日, name_en: entryDate, type: date }
- { name: 開始時刻, name_en: startTime, type: time }
- { name: 受付日時, name_en: receivedAt, type: datetime }
ui:
fields:
- name_en: entryDate
format: { pattern: yyyy/MM/dd }
- name_en: startTime
format: { pattern: 'HH:mm' }
- name_en: receivedAt
format: { pattern: 'yyyy/MM/dd HH:mm' }型は管理する情報を、format.patternは画面での表示を指定します。画面の表示書式と、データ入出力で使う書式は分けて設定します。
UTCオフセット付き日時を追加する例
外部受付日時に時差も保持する場合の抜粋です。通常の受付日時はdatetimeのまま使えます。
entity:
attributes:
- { name: 外部受付日時, name_en: externalReceivedAt, type: offsetdatetime }
この型を指定するだけで、利用者の地域に合わせた表示や、夏時間に対応する予定管理がすべて自動で設定されるわけではありません。必要な入力・表示の方針をAIへ伝え、確認します。
5. 参考資料
- guide:エンティティ属性タイプ
designer/docs/appschema/html/guide/03-model/02-fields.html- reference:entity
designer/docs/appschema/html/reference/06-entity.html- reference:ui
designer/docs/appschema/html/reference/10-ui.html- guide:初期値
designer/docs/appschema/html/guide/05-input-control/01-initial-value.html