処理の流れと項目の対応
- 元の日時
- 形式と地域を確認
- 日付値で比較
- 必要な地域で表示
表示のタイムゾーン変更と、時刻そのものに時間を足す操作を区別してください。
| 項目 | 用途・保存先 |
|---|---|
| local text + source timezone | parseDateで日付値へ変換 |
| date value | 期限や通知区間の比較に使用 |
| date + display timezone | formatDateで表示文字列へ |
日付と時刻の意味を先にそろえる
「11月2日まで」という日付と「11月2日10時」という時刻は別の情報です。前者は業務上の締切時刻を決めてから比較します。例では日本時間の11月2日17時を期限とし、保存する瞬間と画面表示の形式を分けます。日付だけの値を勝手にUTCの0時として扱うと、通知日が変わる場合があります。
元のタイムゾーンを確認する
入力が2026-11-02T01:00:00ZならUTCの時刻を表します。2026-11-02 10:00のように時差がなければ、どこの現地時刻かを送信元で確認します。Makeの組織設定と関数に指定するタイムゾーンを点検し、閲覧しているPCの時刻設定が処理の基準だとは考えないようにします。
parseDateで文字列を日付へ変換する
文字列を比較に使う前に、元の形式と地域を指定して日付値へ変換します。例はparseDate(入力値; "YYYY-MM-DD HH:mm"; "Asia/Tokyo")です。01/02のように月日が曖昧な書式は元の仕様を確認してください。既に日付型の出力なら、不要な文字列化と再解析を繰り返さず、その値を比較に使います。
formatDateは表示用に使う
表示例はformatDate(日付値; "YYYY-MM-DD HH:mm"; "Asia/Tokyo")です。これは表示用の文字列を作る処理であり、元の瞬間を九時間進める操作ではありません。UTCから日本時間への表示変更と、addHoursで時刻そのものを変える操作を混同しないでください。変換済みの値へ再び九時間を足すと二重補正になります。
期限の条件を日付値で比較する
通知対象を「前回確認より後、今回確認まで」のような区間で決め、境界に等しい値をどちらへ入れるかを固定します。表示文字列の大小や日だけの一致で判断せず、日付値と通知済み状態を使います。朝の定期実行が遅れたとき、前の確認以降の対象を回収できるかも考えます。
月末・日またぎ・夏時間を確認する
日本時間の23時59分と翌日0時、月末と翌月初、時差付きと時差なしの同じ瞬間を比較します。海外拠点がある場合は夏時間の切替で存在しない時刻や二度現れる時刻があり、固定の時差だけでは扱えません。地域名を使い、曖昧な現地時刻には送信元で時差を付けるなどの取り決めを設けます。
保存値と通知履歴を残す
元の入力、解釈したタイムゾーン、期限として確定した時刻を区別して記録すると、ずれた理由を追えます。通知は対象IDと通知対象の期限を組にして管理し、期限変更後の再通知も決めます。休業日や祝日の判定は日付変換だけではできないため、業務カレンダーを別に持つ設計へ分けてください。
Makeで小さな自動化から始める
まず練習用データで必要な処理を確認し、利用量と機能に合うプランを選んでください。登録時の料金・特典・適用条件は公式画面で確認できます。
Make公式サイトで登録する広告リンク利用量から費用を確かめる
月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。
費用を試算する参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- Date and time functions — Make情報確認日: 2026-10-30
- Make pricing — Core at 10,000 monthly credits情報確認日: 2026-10-28
- Make credits情報確認日: 2026-10-26
- Make scenario settings情報確認日: 2026-10-26
