Rrule: UTC-しかしUTCではない混乱

私もひどく混乱しています。

わかりました。Readmeに次の重要な段落がありました。

ローカルタイムゾーンには、これら2つのヘルパー機能を使用する必要があります。 tzidをサポートするようにこれを変更する場合は、オフセットを変更してXタイムゾーンのオフセットを取得する必要があります。

/**
 * Mutates date. Add timezone to the date.
 *
 * <strong i="9">@param</strong> {Date} [date]
 */
export function localizeDate(date = new Date()) {
  const offset = new Date().getTimezoneOffset() * 60 * 1000; // get offset for local timezone (can modify here to support tzid)
  date.setTime(date.getTime() - offset);
  return date;
}

/**
 * Mutates a date. De-timezones a date.
 *
 * <strong i="10">@param</strong> {Date} [date]
 */
export function utcifyDate(date = new Date()) {
  const offset = new Date().getTimezoneOffset() * 60 * 1000; // get offset for local timezone (can modify here to support tzid)
  date.setTime(date.getTime() + offset);
  return date;
}

次に、コードは次のように変更されます。

const { RRule, RRuleSet } = require(`rrule`);

const dtstart = localizeDate(new Date());
console.log(`dtstart`, utcifyDate(new Date(dtstart))); // even though it is utc string, this is the local time

const firstHour = dtstart.getUTCHours();
const secondHour = (firstHour + 2) % 24;

const getRRule = options => new RRule(Object.assign({}, options, {
    freq: RRule.DAILY,
    count: 1,
    dtstart,
    byminute: 0,
    bysecond: 0
}));

const showNextInstance = tzid => {
    const ruleSet = new RRuleSet();
    ruleSet.rrule(getRRule({ byhour: firstHour })); // remove tzid as i dont support this
    ruleSet.rrule(getRRule({ byhour: secondHour })); // removed tzid as i dont support this
    console.log('local:', utcifyDate(ruleSet.after(dtstart));
};

showNextInstance(undefined);
showNextInstance(`UTC`);
showNextInstance(`local`);
showNextInstance(`America/Chicago`);

JSの紛らわしく不規則なDate実装に基づいて構築されているため、このライブラリではこれを回避する良い方法はないのではないかと思います。 私は現在完全な書き直しに取り組んでいますが、それを正しくするのに少し時間がかかります。

ありがとう@davidgoliあなたの仕事はとても感謝しています!!!

他の人が不規則な日付の実装を理解するのを助けるために記事を書くことを理解している誰かが必要だと思います。 正直なところ、まだわかりません。うまくいくまで調整しました。

これは、コンソールに出力する返される日付が文字列に変換されるJavaScriptの日付であり、JavaScriptがUTCでコンソールに日付を自動的に出力するためです（タイムスタンプの末尾にある「Z」を参照してください。ゼロオフセット）。 4つのケースのそれぞれでの次の発生は（異なるタイムゾーンではありますが）まったく同時に発生しているため、まったく同じタイムスタンプが4回出力されます。

また、JavaScript Dateオブジェクトは、1970年1月1日木曜日の00:00:00 UTCから経過したミリ秒数を使用して時間を追跡することに注意してください（「UTC」に注意してください）。 「12:34:56 pm」などの文字列の解釈。

@davidgoli

私は現在完全な書き直しに取り組んでいますが、それを正しくするのに少し時間がかかります。

rScheduleのソースを確認することをお見える浮動UTC日付に変換する特別なDateTimeオブジェクト（Luxonからではない）を使用して行われます。 反復はこのUTC日時で行われるため、DSTは問題になりません。 オカレンスが見つかった後、ユーザーに渡される前に、適切なタイムゾーンで通常の日付に変換されます。

例：この日付

import { DateTime as LuxonDateTime } from 'luxon';

const date = LuxonDateTime.fromObject({
  year: 2019,
  month: 1,
  day: 1,
  zone: 'America/Los_Angeles'
})

このUTC日付に変換され、タイムゾーンが保存されます

const fakeDate = Date.UTC(2019, 0, 1)
const fakeDateZone = 'America/Los_Angeles'

このUTC日付はLuxon日付に似ていますが（どちらも2019/1/1ように見えます）、異なるタイムゾーンにあるため、実際には同じ時刻を表していないことに注意してください。

そうは言っても、この特別な「UTC」日付で繰り返すことで、夏時間を気にせずに繰り返すことができます。 正しい日付が見つかったら、ルクソンの日付に戻すことができます。

例えば：

LuxonDateTime.fromObject({
  year: fakeDate.year,
  month: fakeDate.month,
  day: fakeDate.day,
  zone: fakeDateZone,
})

これにより、任意のタイムゾーンをサポートしながら、反復ロジックをUTC対応に保つことができます。

@thefliikプリミティブをダウンさせました。 ここでの本当の頭痛の種は数週間です。 rscheduleも（これまでのところ）byweeknoとbysetposのサポートでパントしているようですが...

ああ、そうだ。 byweeknoは非常に迷惑です。

連絡あった？

私はそれがでconflateの問題には簡単だと思うDateオブジェクトと問題の発生を計算するRRULE私は2つを組み合わせる前に、個別にそれらについての話をするつもりですので、。 私はこれをほとんど書き留めなければならなかったので、問題の理解を整理し、他の人に役立つ場合に備えてここに投稿することにしました。

JavaScriptの日付オブジェクト

JS Dateオブジェクトが不規則であることに同意しませんが、オブジェクトにはよくある誤解があり、そのように見えます。 控えめに言っても混乱します。

@ hlee5zebraで述べたように、 Dateコンストラクターで作成された日付は常にUTCで表されます。 それらは現地時間で表示される場合がありますが、舞台裏では実際にはUnixエポック時間で表されます。 インスタンス化されたDateオブジェクトに対していつでも.getTime()または.toISOString()して、UTCで作業していることを思い出させることができます。

実装は、UTCですべての処理を実行し、ユーザーに表示される現地時間にのみ変換するという規則にも正しく準拠しています。 たまたま、開発者である私たちがユーザーです。 しかしそれから私達は水を濁らせる私達自身のユーザーを念頭に置いています。 アプリを開発するときは、規則に従い、バックエンドで日付をUTCとして保存する必要があります（JSはすでにUTCで日付を処理しているので、そこで問題ありません）。 日付をUTCとしてデータストアに保存する場合、日付はISO文字列としてクライアントに到着し、 Dateオブジェクトによって正しく解析され、ユーザーの現地時間に表示される必要があります。

この記事は、 Dateオブジェクトを理解し、それを使ってどれだけできるかを発見するのに役立ちました： https ：

ルール

RRULEオカレンスの計算は、ユーザーの期待とUTCでの日付の処理に根本的な違いがあるため、注意が必要です。これら2つの時間表現が1日の障壁を超えると顕著になります。

たとえば、ユーザーが毎週火曜日に発生する再発を希望する場合、ユーザーはすべての発生が現地時間の火曜日に発生することを期待します。 ただし、すべての計算はUTCで行われるため、 RRULEようになります。

DTSTART:2019-10-29T00:02:26Z
RRULE:FREQ=WEEKLY;BYWEEKDAY=TU

UTCの火曜日にオカレンスを返しますが、本初子午線のかなり西に位置するユーザーの場合、オカレンスは現地時間の月曜日に表示されます。これは明らかに、誰もが望んでいる結果ではありません。

それを正しくする

とはいえ、これを解決するために開発者がしなければならないことは、JavaScriptにローカル日付が実際にはUTC日付であると考えさせ、その「偽の」日付をrrule.jsに与え、ライブラリに計算を行わせることです。このローカルUTC時間。 .all()メソッドからオカレンスを取得したら、それらの日付の「UTC」部分を使用して、新しいDateオブジェクトをインスタンス化します。 これにより、結果が期待どおりになります。

import { RRule } from 'rrule'

const dtstart = new Date('2019-10-29T00:02:26Z') // same as: `new Date(Date.UTC(2019, 9, 29, 0, 2, 26))`
console.log(dtstart.toISOString()) // 2019-10-29T00:02:26.000Z
console.log(dtstart) // Mon Oct 28 2019 17:02:26 GMT-0700 (Pacific Daylight Time)

const fakeDateStart = setPartsToUTCDate(dtstart)
console.log(fakeDateStart.toISOString()) // 2019-10-28T17:02:26.000Z
console.log(fakeDateStart) // Mon Oct 28 2019 10:02:26 GMT-0700 (Pacific Daylight Time)

const rule = new RRule({
  freq: RRule.WEEKLY,
  byweekday: [RRule.TU],
  count: 2,
  dtstart: fakeDateStart
})

const localUTCOccurrences = rule.all()
console.log(localUTCOccurrences.map(toISOString)) // ["2019-10-29T17:02:26.000Z", "2019-11-05T17:02:26.000Z"]
console.log(localUTCOccurrences) // [Tue Oct 29 2019 10:02:26 GMT-0700 (Pacific Daylight Time), Tue Nov 05 2019 09:02:26 GMT-0800 (Pacific Standard Time)]

const occurrences = localUTCOccurrences.map(setUTCPartsToDate)
console.log(occurrences.map(toISOString)) // ["2019-10-30T00:02:26.000Z", "2019-11-06T01:02:26.000Z"]
console.log(occurrences) // [Tue Oct 29 2019 17:02:26 GMT-0700 (Pacific Daylight Time), Tue Nov 05 2019 17:02:26 GMT-0800 (Pacific Standard Time)]

function setPartsToUTCDate(d) {
  return new Date(
    Date.UTC(
      d.getFullYear(),
      d.getMonth(),
      d.getDate(),
      d.getHours(),
      d.getMinutes(),
      d.getSeconds()
    )
  )
}

function setUTCPartsToDate(d) {
  return new Date(
    d.getUTCFullYear(),
    d.getUTCMonth(),
    d.getUTCDate(),
    d.getUTCHours(),
    d.getUTCMinutes(),
    d.getUTCSeconds()
  )
}

function toISOString(d) {
  return d.toISOString()
}

https://codesandbox.io/s/rrule-localutc-conversion-zxlki

または要するに：

import { RRule } from 'rrule'

const date = new Date('2019-10-29T00:02:26Z')

const rule = new RRule({
  freq: RRule.WEEKLY,
  byweekday: [RRule.TU],
  count: 2,
  dtstart: setPartsToUTCDate(date)
})

const occurrences = rule.all().map(setUTCPartsToDate)

https://codesandbox.io/s/rrule-localutc-conversion-in-short-ez7g0

私が見る限り、Chrome、Firefox、Safariはすべて、コンソールにログインするときに現地時間の文字列として日付を表示し、UTCのISO文字列としてNode.jsを表示します。

@ tim-phillips私も今これに苦しんでいて、それを回避するためのある種のモンキーパッチを探しています。

東部標準時午後8時に定期的なイベントがあり、正常に機能していますが、東部標準時午後9時は、本来あるべき前日にそれを押し戻しています。

あなたがこれに対する答えを見つけることができるかどうか見るのを楽しみにしています。

@ tim-phillipsは優れた内訳です。 まだまだ検討中ですが、ようやく理解できるようになりましたので、よろしくお願いします！

@ tim-phillips分析ありがとうございます。

しかし、次のことを説明できますか？ コンピュータのローカルタイムゾーンによっては、ソリューションが水曜日に戻る可能性があるようです。

@tonylauは、コンソールで文字列化された出力を確認しません。これは、常にローカルタイムゾーンに変換されます。 getUTC*()メソッドを使用して日付の一部を取得する必要があります。これは、ローカルタイムゾーンに関係なく同じになります。

@davidgoli

タイムゾーンをUTC + 14（キリスィマスィ島/ライン諸島時間）に設定すると、getUTCDay（）を使用している場合でも、次のようになります。 その日はまだ火曜日になるはずの水曜日として返されますか？

サンドボックス： https ：

このディスカッションに関連する可能性があります： https ：

@ tim-phillipsありがとう!!!!!!!!!! それはとても役に立ちました!!!!!!! rruleでicを作成する方法を知っていますか？ ノードでicsパッケージを使用すると、再び日の問題が発生します。カレンダーの招待状を受け取ると、休日になります。 （しかし、あなたのコードのおかげで、すべてを正しくデータベースに入れることができます!!どうもありがとうございました。）