はじめに

Notion Tips の第153回目は、parseDate を含む数式をオートメーションで取得する際にちょっとしたハマりポイントがあったので、記録しておきます。多分、これが必要になる人は本当にレアな人だと思いますが、忘れないように記録しておきます。

検証環境の作成

例えばこんなデータベースを考えてみます。YYYYMMDDHHmm に書かれた数値から日付を作成する数式が設定されています。

数式は以下のように記述しています。データベースオートメーションでは、 "Z" でローカルのタイムゾーンが取得できます。これを使って ISO8601 の基本形式の文字列を作り、parseDate() しています。

lets(
    timezone, "00" + today().formatDate("Z"),
    num, prop("YYYYMMDDHHmm"),
    str, num.substring(0, 8) + "T" + num.substring(8) + timezone,
    str.parseDate()
)

データベースオートメーションは以下のように記述しています。

ここで、自分の値は以下のように設定しています。

結果として、YYYYMMDDHHmm を編集すると、リアルタイムに Formula で対応する日付が計算されます。その計算された日付がオートメーションにより、日付プロパティに自動で設定されることになります。実際、上の例では正しく設定されていることがわかります。

問題提起

ほとんどの場合はこれでうまくいくのですが、日本の場合 9:00 の場合に、予想外の結果が出ます。

なぜこうなるのかを検証するために、日本の 0:00 を計算してみます。parseDate は 0:00 の場合には 0:00 が省略されて日付のみの情報になります。

オートメーションはローカルのタイムゾーンを取得することができますが、計算は UTC で行われます。実際日付を確認すると、中の数値は UTC のタイムゾーンで登録されていました。表示は日本時間の 11/22 0:00 になっていますが、中身は UTC の 11/21 15:00 なのです。

再度 9:00 に戻して同じように確認してみます。この時、UTC の 0:00 になってしまうので、日付形式になってしまい、タイムゾーンの情報が失われてしまいます。

回避手段

実際に 9:00 のような綺麗な時間が正しく生成されないのは困ります。そこで、ちょうど 0 分の場合に 1 に変更してしまいましょう。すなわち、parseDate をする直前で数値を 1 加えて 9:01 に変更してしまいます。その後、parseDate 完了後に 1 に変更した場合だけ足してしまった 1 分を減算します。数式を以下のように変更しました。

lets(
    timezone, "00" + today().formatDate("Z"),
    num, prop("YYYYMMDDHHmm"),
    offset, num % 100 == 0 ? 1 : 0,
    str, num.substring(0, 8) + "T" + (num + offset).substring(8) + timezone,
    str.parseDate().dateSubtract(offset, "minutes")
)