MS Plannerのグリッドビューで作成したタスク期限の日時ズレ

2024-12-13

当サイトには広告を含みます。

当サイトでは、広告掲載ポリシーに沿って広告を掲載しています。
※広告でなく、単に商品やサービスを自主的に紹介しているだけという場合もあります。

"オススメ" として紹介している商品やサービスは、個人的にそう思えたものだけです。

共感、興味をもっていただけるものがあればご利用ください。

ふるさと納税の期限間近

経緯

まず、Plannerのタスク期限の日時がズレることがある事象(以降、本事象と呼ぶこともあり)に気付いたきっかけを簡単に説明します。

PlannerのUI上は、タスクで設定できる期限は日付部分(2024-12-01など)のみを扱うため、時刻部分(13:45など)を意識することはありません。ただ実際には、日付だけでなく時刻も含む日時情報を保持しているようです(コネクタ経由で取得できるdueDateTime)。

今回、他のサービス(Power Automate)からPlannerのタスクの情報を取得する操作(フロー実行)をした際に、Power Automate側でタスクの期限に関する判定が意図しない結果になるケースがあったので、本事象に気付きました。

具体的には、Power Automate側のテンプレート、”翌日が期限の Planner タスクに関するメッセージを日次で Microsoft Teams に投稿する(Post a daily message to Microsoft Teams with Planner tasks due tomorrow)” から作成したフローの実行時です。

ちなみに、Planner標準でタスクの通知機能があるので、それで十分なら上記のようなPower Automateのフローなどを使用する必要性はありません。

期限の日時がズレる事象の概要

本事象の概要です。

例として、Plannerで期限が2024年12月1日のタスクを作成した場合を挙げます。

通常？のタスク作成時は、指定日のUTC 10:00

通常？のタスク作成時は、そのタスクの期限(dueDateTime)をPower Automateで取得してみると、以下のようになります。

dueDateTime：2024-12-01T10:00:00Z
(UTCで10:00なので、JSTで19:00)

“通常”というのは、私がちょっと確認した範囲ではありますが、Plannerで作成したタスクの期限の日時は、後述のグリッドビューから作成した場合を除き、指定した日付のUTC 10:00に設定されるという意味です。それが”通常”であるという公式なソースは見当たりませんが(補足事項は後述)。

便宜上、本記事では、グリッドビュー以外のビュー(ボード、スケジュール、グラフ)からタスク作成することを、”通常”のタスク作成方法と呼ぶことにします。もちろんグリッドビューからのタスク作成がすべて異常だという意味ではなく、正常系と異常系を区別するためのものです。

グリッドビューからタスク作成時は、前日のUTC 15:00

一方、Plannerのグリッドビューから繰り返しの無いタスクを作成した場合にのみ、そのタスクの期限の日時情報(dueDateTime)が異なる値になってしまいます。

dueDateTime：2024-11-30T15:00:00Z
(JSTだと00:00、UTCだと前日の15:00)

12月1日を指定したはずなのに、前日の11月30日になっています。他の操作方法でも同様の事象が発生するかもしれませんが、とりあえず私の試した範囲では、このような動作でした。

なお、ローカルタイムがJST以外の環境での動作は未確認です。もしかすると、期限として指定した日付をローカルタイムの00:00で設定する動作なのかもしれません。

日時のズレ方と影響

上記のように日時がズレる本事象を簡単に整理してみます。

日時のズレ方をまとめると

私の試した範囲では、タスクの期限を日付Aに設定した場合、そのタスクの期限の日時情報(dueDateTime)を取得すると以下のようになります。

	Planner上の期限	dueDateTime(UTC)	(参考)JST換算のdueDateTime
通常のタスク作成	日付A	日付A(当日) 10:00	日付A(当日) 19:00
グリッドビューから繰り返しの無いタスクを作成した場合のみ	日付A	日付Aの前日 15:00	日付A(当日) 00:00

ローカルタイムがJST以外の環境での動作は未確認です。UTC -12:00の環境でタスクを作成するとどうなるかなど。

例えば、タスク1を通常の方法で、タスク2をグリッドビューからの方法で作成した際には、両方のタスクの期限として同じ日付を指定したとしても、その期限の日時情報(dueDateTime)を取得し、UTCのままで扱うと、タスク1の期限は当日に、タスク2の期限は前日になってしまうということです。時間数で表すと19時間分のズレに相当します。

なお、JSTに変換すると同じ日付になります。

時刻単位で扱うと不具合があるかも

いったん繰り返しますが、PlannerのUI上は、タスクの期限としてローカルタイムでの日付部分のみが表示されるようなので、基本的に違和感も不都合もありません。

しかし、他サービス、例えば私のようにPower Automateでタスクの期限(dueDateTime)を取得した際に、上記のように期限の日時がズレたタスクが混じっていると、タイムゾーンの扱い方にもよりますが、そのズレが表面化するケースがあります。特に、日付単位でなく時刻単位で処理をする場合には、19時間ズレた日時データを扱うことになります。

その結果、タスク間での意図しない期限の不整合や、Plannerで見えている日付との差異が生じ、不具合につながるかもしれません。

その他、Plannerだけを利用していたとしても、複数のタイムゾーン間(マルチタイムゾーン)でタスクの期限を管理している場合には、期限の判定やPlanner標準の通知が変な動きをしないのかな、と気になりました。

既にデータはズレてるかも

Plannerを使用しているユーザが、どのビューでタスクを作成するかは分かりません。

グリッドビューでタスクを作成することもあるでしょうし、他のビューから作成することもあるでしょう。そのため、既に作成されたタスクの期限は、ズレているかもしれません。

あまり無いけど対処など

あまり良い方法は無いでしょうが、本事象に関し、いくつか思いついた対処を書いておきます。

基本的に、元の日時データがまずい状況なので、後続の処理で不用意にデータ補正すべきではないと思います。

Plannerの期限に厳密さを求めず運用する(気にしない)

まず、全く解決していませんが確実な方法です。

単一のタイムゾーン内でPlannerだけを使用している分には不具合は無いでしょうし、気にしなくて良いと思います。期限に余裕をもって行動さえすれば…。

他サービスでPlannerからタスクの情報を取得したり、マルチタイムゾーンでのコラボレーションを行ったりする必要性が生じたときに、改めて検討するくらいの感覚です。

Microsoftに直してもらう()

でも直ってはほしいですね。Plannerの画面からフィードバックはしてありますが、直してはくれない気もします。

なお、現状の動作に合わせて作り込んである仕組みがある場合には、急に予告なく直ったら直ったで問題が起きるかもしれません。しかも直る前に作成されたタスクの期限の日時データまでは直らないでしょうし。

作成済みのタスクの期限だけを修正する

既に存在するタスクのうち、本事象が発生して期限の日時がズレたものだけを修正する処理を用意して自動的に定期実行するような方法も考えられます(参考)。対象のタスクのdueDateTimeを一律+19時間するなど。

ただし、このようにデータ自体を修正する操作は、先にMicrosoftのサポートに対処としての妥当性は確認したいところ。

あるいは、手作業でも良ければ、これも細かくは試していませんが、”グリッドビューから繰り返しの無いタスクを作成” する以外の方法であれば、既に作成済みのタスクの期限を編集して上書き保存するだけでも、そのタスクの期限は ”通常” の作成方法の場合と同じ日時に更新されるようです。

主に使用するタイムゾーンに揃えて処理する(推奨ではない)

Plannerから取得したタスクの期限に基づいて処理をする場合を想定した対処案です。推奨できませんが、小手先の対処として。

日時データをすべて特定のタイムゾーン(JST等)に揃えて処理するよう変更すれば、そのタイムゾーン内の運用においては日付単位の不具合は回避できます。ただし時刻部分はズレたままなので、時刻単位の不具合がある場合には回避できません。

なお、タイムゾーンの統一に関しては、もともとそういう運用なら良いと思うのですが、この不具合を回避するためだけにタイムゾーンの扱いに制約を加えるというのは避けたいところ。別の契機で不都合が生じるかもしれません。マルチタイムゾーンでのチームのやり取りなど。

設定例

前述のPower Automate側のテンプレート、”翌日が期限の Planner タスクに関するメッセージを日次で Microsoft Teams に投稿する(Post a daily message to Microsoft Teams with Planner tasks due tomorrow)” の場合を例に、記載しておきます。

このテンプレートには、翌日が期限のタスクを抽出するために以下の条件が登場します。

and(equals(formatDateTime(item()?['dueDateTime'], 'yyyy-MM-dd'), formatDateTime(addDays(utcNow(), 1), 'yyyy-MM-dd')),less(items('Apply_to_each')?['percentComplete'], 100))

上記の条件は、item(前段の処理でPlannerから取得したタスク)のdueDateTime(期限)が翌日だった場合、かつpercentComplete(完了率)が100％未満だった場合にTrueとなるものです。item()?['dueDateTime']や、utcNow()は日時データであり、UTCです。

この条件のうち、以下の2箇所を変更します。

1箇所目
変更前：formatDateTime(item()?['dueDateTime'], 'yyyy-MM-dd')
変更後：formatDateTime(convertTimeZone(item()?['dueDateTime'],'UTC','Tokyo Standard Time')

2箇所目
変更前：formatDateTime(addDays(utcNow(), 1), 'yyyy-MM-dd')
変更後：formatDateTime(addDays(body('タイム_ゾーンの変換'), 1)
※前段にタイムゾーンの変換アクションにて、UTC+09:00(JST)に変換した時刻を用意して、それを使用するというものです(参考１，参考２)。

この変更により、取得した期限の日時をUTCでなくJSTで比較することになります。前述のとおり、日付単位ではズレなくなります。ただし時刻はズレたままです。

(参考) 指定した日付のUTC 10:00になる動作

前述のとおり、”通常” はPlannerで作成したタスクの期限の日時は、指定した日付のUTC 10:00に設定されるようです。それが仕様であるという公式なソースは見当たりませんが、以下のような投稿はありました。

Planner stores the date picked in the UI as 10 AM UTC of the picked date. That specific value causes the Local time equivalent to be in the same date as most places.
出典：Microsoft planner startDate/dueDate timezone? – Stack Overflow

ある日付を時刻も含めたデータとして保存する場合に、UTCでその日付の午前10時にしておくと、世界中のほとんどの地域のタイムゾーンにおいても同じ日付になるようで。ちょっと調べてみたら、確かに…という感じの豆知識。