CosmosDBストアード・プロシージャー内の日付の作成と比較

Question

CosmosDBストアード・プロシージャーとその処理については、new Date()のガイダンスと日付の比較については制限があります。

次のコードは、一定時間後に文書の書き込みを「フリーズ」するためのCosmosDBストアドプロシージャです。プロパティcurrentDoc.FreezeDateはISO-8601形式です（例： '2017-11-15T13：34：04Z'。

注：これは私が理解しようとしている状況の例です。プロダクションコードではありません。

function tryUpdate(newDoc) { 
    __.queryDocuments(
    __.getSelfLink(), 
    { /* query to fetch the document */ }, 
    (error, results) => { 
     var currentDoc = results[0]; // doc from the database 
     // fail if the document is still locked 
     if (new Date(currentDoc.FreezeDate) < new Date()) { 
     getContext().getResponse().setBody({ success: false }); 
     return; 
     } 
     // else update the document 
     /* snip */ 
    } 
); 
} 

私の質問は：CosmosDBストアドプロシージャ内で、特にデータベースは、呼び出しコードとは異なる領域であってもよいことを考えると、タイムゾーンによって影響new Date()ですか？すべての状況で日付比較コードが有効ですか？

Answer 1

私が見る限り、CosmosDBは対応するTimezone、akaを付けずにDateTime値を格納しています。 DateTimeOffsetとしてではありません。それは、常にこのようなものに正規化されているので、これは、コードが実行された場合、それは問題ではないはず意味：

"2014-09-15T23:14:25.7251173Z" 

JavascriptのDateオブジェクトをタイムスタンプされている - 彼らは単にエポックからのミリ秒数が含まれています。 Dateオブジェクトには、タイムゾーン情報はありません。このタイムスタンプが表すカレンダーの日付（日、分、秒）は、解釈の問題です（to ... Stringメソッドの1つ）。つまり、（Parse date without timezone javascriptから取られた）

は、あなたが世界の関係なくは、new Date()は常に内部的に同じ値を持つことになります。

可読性のために不確実性を取り除きたい場合は、エポック（Unix Time）から秒またはミリ秒を保存することをお勧めします。これはまた、日付（new Date().value - ミリ秒）で内部的に使用されるものです。ちなみに、内部コスモス文書フィールド_tsは、エポック形式のタイムスタンプでもあります。

new Date()の値は、「正しいグローバル時間」を2〜3分でオフにする可能性があることに注意してください。Azure/Cosmosが特定の偏差ウィンドウを保証しているかどうかはわかりません。