TV会議端末バージョンアップ後、マクロが予期せぬ動きをする

[shoko-fukami]

＜状況＞

CiscoTACではマクロ関連のQAは受け付けていないとのことで、こちらで質問をさせてください。

2020年3月に以下のバージョンでRoomkit系のデバイスにマクロ機能を設定しました。 マクロは指定時間に自動切断するものです。

しかし、最近このマクロが動作しなくなり、端末のログを確認したところ指定した時刻より9時間ズレて切断処理が行われているようです。

導入当時のバージョン：RoomOS 2020-04-06 dbcdd81ba03

現在のバージョン：RoomOS 10.7.1.2 05b751884cf

※端末はクラウドレジスト構成

＜マクロ＞
function scheduleDisconnect(time, callback) {
let [alarmH, alarmM] = time.split(":");
let now = new Date();
now.setHours(now.getHours()); ★導入時はこの設定で日本時間の夕方に切断されていたが、現在はここに+9して日本時間に合わせる必要がある。
now = now.getHours() * 3600 + now.getMinutes() * 60 + now.getSeconds();
let difference = parseInt(alarmH) * 3600 + parseInt(alarmM) * 60 - now;
if (difference <= 0) difference += 24 * 3600;
setTimeout(callback, difference * 1000);
}

＜質問＞

getHours()の仕様が、導入時はJSTだったにも関わらずUTCで読み込まれているように見えますが、

マクロの仕様変更があったのでしょうか。

ちなみに、導入後、端末やマクロの設定変更は一切していません。

[Tohru Ohzono]

こんにちは。

ECMAScript / JavaScriptの仕様としては、
Date.getHours()などはローカルタイムの値を返す仕様なので、
現象見る限りは不具合だと思います。
開発チームには連絡や確認はしておきます。

回避策に関しては、現在の暫定修正方法だと、この事象が不具合認定されて修正されたあとに、
再度９時間ズレることになるので、以下のような方式にすると、
修正後も動作する可能性が高まると思います(完ぺきではありません)。

■ 方法1
UTCベースで実装する方法です。
now.getHours()などを、すべてUTCベースの、
now.getUTCHours()/getUTCMinutes()/getUTCSeconds()などに置き換えます。

const disconnectTime = "17:30"
の部分をUTCベースの時刻で指定することになります。

※ この方法と現在のアルゴリズムの組み合わせでは、重大な欠点があって、
日本時間(もしくはUTC+9のタイムゾーン)に限定した場合、日本時間の09:00(UTCの00:00)以前に指定すると期待しない動作になります。
運用上このケースがないことが期待できるのであれば、使える実装かなと思います。

■ 方法2

端末側の時刻取得APIを利用する方法です。

https://roomos.cisco.com/xapi/Status.Time.SystemTime/

マクロ上は、以下のような感じでデバイスの時刻が取得できます。

xapi.Status.Time.SystemTime.get().then((value) => {
    console.log('SystemTime: ' + value)
})

文字列として取得できる情報なので、これをパースする必要があるのが課題になります。
現状、Date自体の動作に問題がありそうで、new Date(取得した文字列)などを行っても、期待した動作にはなりませんので、
独自にパースするなどの必要が出てくると思います。

以上、よろしくお願いします。

[Tohru Ohzono]

本件、さきほどの投稿のアップデートになります。

開発チームと話して、不具合としてケースは作成してもらいました。
今後修正されると思いますが、現時点で時期等は未定となります。

まだ調査始まったばかりですが、内部的なUTCからのオフセット値が期待した値になっていないので、
このあたりが根本原因かもしれません。

DateにはgetTimeZoneOffset()メソッドがありますが、こちらもUTCとズレたタイムゾーンであっても
期待した値は返さず、常に0を返すような問題がある動作になっています。

[shoko-fukami]

Ohzono様

返信いただきありがとうございます。

不具合登録されたとのこと承知しました。

回避方法については共有いただいたサンプルを参考に検討してみます。

今後、開発部門から情報が出てくるのかもしれませんが

本件は端末バージョンアップに起因するJavaScript の不具合ものなのでしょうか。

端末のバージョンアップは特に関係なくJavaScript 側だけの不具合なのでしょうか。

基本的な質問になるかもしれませんが、VC端末のバージョンとマクロを実装するJavaScript の仕様（バージョン？）の

関係性がよく理解できていません。

お客様に説明するにあたり、ご教示いただけますと幸いです。

[Tohru Ohzono]

こんにちは。

本問題は、RoomOSのアップグレードに伴う、
RoomOS内部に標準的に組み込まれているマクロのランタイム(マクロ関連のJavaScript実行エンジン)関連の不具合となります。

マクロ関連の機能自体はRoomOSの標準機能なので、RoomOS上で動作するように標準的に組み込まれており、
今回はご指摘のあったRoomOSバージョンに組み込まれていたマクロのランタイムに不具合があったということになります。

今回の問題に関しては、マクロのランタイムの改修で解決する見込みではありますが、
現在個別コンポーネント単位でのパッチ形式のような提供は行っていないと思うので、
今後のRoomOSのアップグレードにて修正も提供されることになると思います。

以上、よろしくお願いいたします。

[shoko-fukami]

マクロのランタイムに不具合があったとのこと、承知しました。

不具合改修後も影響を受けない形でマクロの修正を行ってみます。

今回のBug IDが分かれば教えてください。経過を確認しておこうと思います。

[Tohru Ohzono]

こんにちは。

提示した方法は、UTCベースの実装で、getUTCXyz()はマクロエンジン修正後もUTCベースの情報を返すことが期待されるため、
マクロエンジン修正版を適用後も同じ動きをすることは期待できます。

ただ、時刻の設定部分もUTCベースになってメンテナンス性は劣ると思うので、
タイミング見てコードはもとに戻すことを考えたほうがいいかもしれません。

不具合のIDに関してですが、現時点では、開発チーム側のシステムに登録している状態で、
公開されている不具合のIDがありません。
現状は担当者はアサインされている状態で優先度に関する評価を行っている状況です。

開発側のシステムに登録されているのでこのまま最適な形で進むと思います。

私は状況確認できるので情報のアップデートはできると思いますが、

コミュニティ対応となるので、ベストエフォートになる点ご了承いただければと思います。

以上、よろしくお願いします。

[shoko-fukami]

時刻指定はJSTで指定し、時刻比較の際に、指定した時刻と現在時刻の両方をUTCに変換するようにマクロを修正してみましたので、こちらを適用し様子をみてみます。

ベストエフォートで結構ですので、改修完了しましたらこちらにUpdateいただけますと幸いです。

[Tohru Ohzono]

こんにちは。
本件、内部での修正は完了しました。
今後のリリースにて修正適用済みとなる見込みです。
予定では、2021年11月のリリースになると思います。

原因に関して細かい実装内容等は開示できませんが、
簡単に説明すると、
マクロのランタイム内部でタイムゾーン情報の取得に失敗する状態になっており、
その際にUTCにフォールバックする実装であったため、
UTCとして処理されていたことになります。

以上、よろしくお願いします。