Notionの日付プロパティは、見た目より複雑なことをしています。日付だけを入れることも、時刻まで入れることも、期間にすることもできる。さらにタイムゾーンも指定できます。
この柔軟さが、時差をまたぐチームで効いてきます。入れたはずの情報が、入れたとおりには保存されていない場面があるからです。
実際にいろいろな形で日付を入れて、何が返ってくるかを測りました。結論を先に言うと、タイムゾーンの名前は残りません。
入れたものと、返ってくるものが違う
まず、入れ方によって返りがどう変わるかを見ます。
4つの入れ方を試した
日付だけ、時刻つき、オフセットつき、タイムゾーン名つき。この4パターンで入れて、そのまま読み返しました。
| 入れたもの | 返ってきたもの |
|---|---|
| 2026-09-30 | 2026-09-30（そのまま） |
| 2026-09-30T09:00:00Z | 2026-09-30T09:00:00.000+00:00 |
| 2026-09-30T09:00:00+09:00 | 2026-09-30T09:00:00.000+09:00 |
| 時刻＋タイムゾーン名（東京） | 2026-09-30T09:00:00.000+09:00 |
日付だけなら、何も起きない
日付だけを入れた場合は、そのまま返ってきます。時刻の情報を持たないので、時差の影響を受けません。
締切や記念日のように、時刻が関係ないものは、この形にしておくのがいちばん安全です。余計な変換が起きる余地がありません。
時刻を入れると、オフセットが付く
時刻まで入れると、必ずオフセットが付いた形で返ってきます。末尾の「+09:00」のような部分です。
末尾にZを付けて入れた場合は「+00:00」になりました。Zは世界標準時を表す書き方なので、同じ意味の別表記に置き換えられた形です。
タイムゾーン名は保存されない
ここが今回いちばん重要なところです。
名前を入れても、返りでは消えている
日付を入れるとき、タイムゾーンを名前で指定できます。「Asia/Tokyo」のような形です。
実際に名前を指定して入れてみると、正しく解釈されて「+09:00」に変換されました。ここまではいい。問題は、タイムゾーンを記録する欄が空のまま返ってくることです。
つまり、保存されているのはオフセットだけで、「東京時間で指定した」という情報は残っていません。
何が困るのか
オフセットが残っていれば、時刻としては正確に復元できます。そこは問題ありません。
困るのは、あとから日付を動かしたときです。タイムゾーン名がないと、その地域で今どのオフセットを使うべきかを判断できません。
日本のように一年中オフセットが変わらない地域なら、実害はほぼありません。問題になるのは、夏時間のある地域です。
夏時間はどう扱われるのか
夏時間のある地域を指定して、時期を変えて試しました。
入れた時点では、正しく判定される
| 指定 | 返ってきたオフセット |
|---|---|
| ニューヨーク・7月 | -04:00（夏時間） |
| ニューヨーク・1月 | -05:00（標準時） |
| 東京・7月 | +09:00 |
| ロンドン・7月 | +01:00（夏時間） |
同じニューヨークでも、7月は-04:00、1月は-05:00になっています。その日付の時点で夏時間かどうかを見て、正しいオフセットに変換しています。ここはよくできています。
ロンドンも、7月は+01:00でした。冬なら+00:00になる地域です。
問題は、変換したあと
正しく変換されるのに、変換のもとになった地域名は保存されません。残るのはオフセットだけです。
たとえば、7月の予定を-04:00で登録したあと、その予定を1月に移したとします。このとき、オフセットは-04:00のまま動きません。現地では-05:00であるべきなのに、1時間ずれたままになります。
自動化で日付を書き換える処理を組んでいる場合、ここが効いてきます。日付だけを変えて、オフセットをそのままにすると、冬と夏をまたいだ瞬間にずれます。
図にすると、こういう流れです
弾かれる入れ方が2つある
エラーになる組み合わせも確認しました。どちらも、知らないと原因が分かりにくいものです。
終了が開始より前だと通らない
期間として日付を入れるとき、終了が開始より前だとエラーになります。「開始は終了より前でなければならない」というメッセージが返りました。
手で入力しているぶんには起きませんが、自動化で期間を計算しているときには起こり得ます。引き算の向きを間違えていたり、入れ替わったデータが来たりしたときです。
この場合、書き込み自体が失敗します。途中で止まるので、気づけるぶんまだ親切なエラーです。
時刻なしでタイムゾーンを指定すると通らない
もう1つが、日付だけを入れながらタイムゾーンを指定したケースです。こちらもエラーになりました。
メッセージには「タイムゾーンを明示するなら、開始と終了に時刻が必要」とあります。考えてみれば当然で、時刻がなければタイムゾーンを当てはめる先がありません。
日付だけで管理したいなら、タイムゾーンは指定しない。時差を扱いたいなら、時刻まで入れる。この2択になります。
地域名のつづりが違うと通らない
ついでに、存在しない地域名を入れてみました。こちらもエラーで弾かれ、使える地域名の一覧が返ってきます。
つまり、つづりの間違いは書き込み時点で分かります。黙って無視されて、あとから時刻がずれる、という事故は起きません。
絞り込みは日付単位で動く
もう1つ、実務で効く挙動を確認しました。
時刻つきの行も、日付で拾える
日付で絞り込むとき、時刻つきの行がどう扱われるかを試しました。特定の日付と一致するもの、という条件で検索したところ、その日に含まれる時刻つきの行もすべて返ってきました。
時刻が9時でも15時でも、同じ日なら一致します。つまり絞り込みは日付の単位で動いていて、時刻までは見ていません。
これは便利だが、境目に注意
「今日の予定」を出すような使い方では、この挙動が便利です。時刻を気にせず日付だけで書けます。
気をつけるのは、日付が変わる境目です。どのタイムゾーンから見た「その日」なのかで、拾われる行が変わります。深夜の予定が前日に入ったり翌日に入ったりするのは、この境目の問題です。
時差をまたぐときの設計
ここまでを踏まえて、実際にどう作るかを整理します。
1. 時刻が要らないなら、日付だけにする
いちばん確実なのがこれです。締切、提出日、記念日。時刻に意味がないものは、日付だけで持ちます。
日付だけなら時差の影響を受けません。誰がどこから見ても同じ日付です。悩む余地がないので、迷ったらこちらに寄せます。
2. 時刻が要るなら、地域名を別の列に持つ
時刻まで必要な場合は、日付プロパティとは別に、どの地域の時刻なのかを記録する列を作ります。テキストでもセレクトでもかまいません。
セレクトにしておくと、選択肢が固定されるので入力のばらつきが減ります。扱う拠点が決まっているなら、こちらが楽です。
この列があれば、あとから日付を動かすときに、その時期の正しいオフセットを計算し直せます。日付プロパティだけでは、この計算ができません。
3. 自動化で日付を動かすときは、作り直す
すでにある日付の「日」の部分だけを書き換える処理は、夏時間のある地域で事故ります。オフセットが古いまま残るからです。
代わりに、地域名と新しい日時から日付の値そのものを組み立て直します。タイムゾーン名を指定して入れ直せば、その時期の正しいオフセットに変換されます。
手間は変わりません。文字列を部分的に書き換えるか、作り直すかの違いだけです。作り直すほうが安全です。
4. 国内だけなら、ここまでは要らない
最後に線引きをしておきます。扱う相手が日本国内だけなら、ここまでの対策はほぼ不要です。
日本は一年を通してオフセットが変わらないので、+09:00が残っていれば常に正しい時刻になります。地域名を別に持つ意味も、作り直す意味もありません。
海外の拠点やメンバーが関わるようになった時点で、この記事の話に戻ってきてください。
よくある質問（FAQ）
タイムゾーンを指定したのに、設定が残っていません。
仕様です。指定した地域名はオフセットへの変換に使われるだけで、保存されるのはオフセットだけでした。タイムゾーンを記録する欄は空のまま返ります。地域名を残したい場合は、別のプロパティに持たせてください。
夏時間は考慮されますか。
入れる時点では考慮されます。ニューヨークを指定して7月の日付を入れると-04:00、1月なら-05:00になりました。ただし保存されるのはそのオフセットだけなので、あとから日付を別の季節に動かすと、オフセットが古いまま残ります。
日付だけを入れたいのですが、時刻が勝手に付きますか。
付きません。日付だけを入れれば日付だけが返ります。時刻の情報を持たないので、時差の影響も受けません。時刻に意味がないものは、この形にしておくのが安全です。
期間を入れたらエラーになりました。
終了が開始より前になっている可能性があります。この組み合わせは書き込み時点で弾かれ、「開始は終了より前でなければならない」というメッセージが返ります。自動化で期間を計算している場合は、引き算の向きを確認してください。
日付で絞り込むと、時刻つきの行も出てきます。
そういう動きです。絞り込みは日付の単位で判定されるので、同じ日であれば時刻が何時でも一致します。時刻で絞りたい場合は、条件を工夫するか、時刻を別のプロパティに分ける必要があります。
国内だけで使うなら、何か対策が要りますか。
ほぼ不要です。日本は一年を通してオフセットが変わらないので、保存された+09:00が常に正しい時刻を指します。地域名を別に持つ必要も、日付を作り直す必要もありません。
時刻が要らないなら、日付だけにする
時差の問題の多くは、時刻を持たせたことから始まります。締切や提出日のように時刻に意味がないものを日付だけにしておくだけで、悩む場面がかなり減ります。手元のデータベースで一度見直してみてください。