创建和比较CosmosDB存储过程中的日期 [英] Creating and comparing dates inside CosmosDB stored procedures

问题描述

对CosmosDB存储过程及其处理新Date（）以及日期比较的指导有限。

There is limited guidance for CosmosDB stored procedures and their handling of new Date() and the comparison of dates.

以下代码是一个CosmosDB存储过程，用于在给定时间后冻结文档的写入。属性 currentDoc.FreezeDate 采用ISO-8601格式，例如'2017-11-15T13：34：04Z'。

The following code is a CosmosDB stored procedure to 'freeze' the writing of documents after a given time. The property currentDoc.FreezeDate is in ISO-8601 format, e.g. '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存储过程中，是新的Date（）受时区的影响，特别是考虑到数据库可能与调用代码位于不同的区域？这里的日期比较代码是否在所有情况下都有效？

My question is: within CosmosDB stored procedures, is new Date() affected by timezones, especially given that the database may be in a different region than the invoking code? Is the date comparison code here valid in all situations?

推荐答案

据我所知，CosmosDB存储的是DateTime值，而不是相应的时区，又名。不是DateTimeOffset。这意味着代码执行的位置无关紧要，因为它总是被标准化为这样：

As far as I can see, CosmosDB is storing DateTime values without the corresponding Timezone, aka. not as DateTimeOffset. This means it should not matter where the code is executed, since it is always normalized to something like this:

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

Javascript日期对象是时间戳 - 它们仅仅包含自纪元以来的毫秒数。 Date对象中没有时区信息。此时间戳表示的日历日期（日，分，秒）是解释的问题（对......字符串方法之一）。

Javascript Date object are timestamps - they merely contain a number of milliseconds since the epoch. There is no timezone info in a Date object. Which calendar date (day, minutes, seconds) this timestamp represents is a matter of the interpretation (one of to...String methods).

（取自没有时区javascript的解析日期）

换句话说，无论你在世界的哪个地方， new Date（）在内部总是具有相同的值。

In other words, no matter where you are in the world, new Date() will always have the same value internally.

如果你想消除不确定性以换取可读性，我建议只存储自纪元以来的秒或毫秒（Unix时间）。这也是日期内部使用的内容（ new Date（）。value - 毫秒）。顺便提一下，内部cosmos文档字段 _ts 也是epoch格式的时间戳。

If you want to remove uncertainty in exchange for readability, I would recommend only storing the seconds or milliseconds since the epoch (Unix Time). This is also what is used internally by date (new Date().value - milliseconds). Incidentally, the internal cosmos document field _ts is also a timestamp in epoch format.

请注意， 新的Date（）可能会在几分钟之内关闭'正确的全球时间' - 我不知道Azure / Cosmos是否保证某个偏差窗口。

Be aware that the value of new Date() might by off the 'correct global time` by a couple of minutes - I don't know if Azure/Cosmos guarantees a certain deviation window.

这篇关于创建和比较CosmosDB存储过程中的日期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！