コンソールの警告が表示されていますか？ 例えば：

'Using TZID without Luxon available is unsupported. Returned times are in UTC, not the requested time zone'

LuxonはoptionalDependenciesにあるため、 node_modulesにある場合はインポートされますが、そうでない場合はインポートされます。

rruleテストスイートでコードを実行すると、次のようになります。

      [
        [Date: 2018-11-01T19:00:00.000Z]
        [Date: 2018-11-05T19:00:00.000Z]
        [Date: 2018-11-07T19:00:00.000Z]
        [Date: 2018-11-08T19:00:00.000Z]
        [Date: 2018-11-12T19:00:00.000Z]
        [Date: 2018-11-14T19:00:00.000Z]
        [Date: 2018-11-15T19:00:00.000Z]
      ]

あなたが要求した時間はデンバーのタイムゾーンで1900年なので、これは私が期待していることです。 （これはJavaScriptでありPHPではないため、ローカルマシンのタイムゾーンまたはUTC以外のタイムゾーンでDateオブジェクトを提供することはできません。したがって、UTCはこのライブラリが常に使用するものです。）

UTCの日付ではなくローカル（MST / MDT）の日付が表示されているという事実は、私には少し困惑しています。 私の知る限り、このライブラリは現在、UTC日付のみを返すように構成されていますが、以前は代わりにローカル日付を返していました。

コンソールの警告が表示されていますか？ 例えば：

'Luxonを使用せずにTZIDを使用することはサポートされていません。 返される時間はUTCであり、要求されたタイムゾーンではありません。

コンソールの警告はありません。 Luxonは適切に提供されているようです。

タイムゾーンに関しては、Chromedevtoolsコンソールのコマンドラインでコードを直接実行した結果としてMST / DSTが取得されます。

手順：Chromeを開く-> RRuleとLuxonが提供されているページに移動-> Cmd + Opt + I-> [コンソール]タブ->上のスニペットをコピーして下部のコマンドラインに貼り付ける-> Enter

このライブラリは現在、UTC日付のみを返すように構成されていますが、以前は代わりにローカル日付を返すために使用されていました。

これがどのバージョンで変更されたか知っていますか？ なぜその変更が行われるのでしょうか？ UTC日付のみを返すと、実際にはこの夏時間の不一致が発生します。 常に13：00UTCに発生するイベントは、夏時間の切り替えの前後の異なる時間にイベントが開始されることをほぼ保証します。 この変更を元に戻すか、夏時間を考慮できる別の代替方法を提供する必要があると思います。 UTCは非常に便利ですが、すべての状況で常に正しいアプローチであるとは限りません。 定期的なイベントを処理する場合、特に夏時間が重要であるため、イベントが発生する特定のタイムゾーンを考慮する必要があります。

実際、Chromeの動作はNodeの動作とは異なります。

私はあなたの与えられた「期待される」出力があなたが本当に期待しているものである理由を理解していないと思います。 それらの時間は正しくないように見えます。

正しいのは、指定された現地時間に各時間のTZオフセットを追加した場合の時間です。 その後、すべての時間は19:00になります。 これが、RRuleがUTCを扱う理由であり、UTCの使用がこの特定のバグとは何の関係もない理由です。

確かに、あなたがそうするならば：

const dates = RRule.fromString(
  "DTSTART;TZID=America/Denver:20181101T190000;\n"
  + "RRULE:FREQ=WEEKLY;BYDAY=MO,WE,TH;INTERVAL=1;COUNT=7"
).all()
dates.map((date) => date.toISOString())

一貫して正しい日付と時刻で結果のISO文字列が表示されます。

さらに、ChromeはUTCでの日付の返送をまったくサポートしていないようです。

> new Date(Date.UTC(2016, 10, 5))
Fri Nov 04 2016 17:00:00 GMT-0700 (Pacific Daylight Time)
// ^ I asked for a date in UTC, not in PDT!

RRuleは、Luxonを使用して、ローカルタイムゾーンだけでなく、_世界のすべてのタイムゾーン_の正しい現地時間を生成します。 これがUTCの使用が重要である理由です。タイムゾーンコードがローカルタイムゾーンの「正しい」日付を返したが、別のタイムゾーンで日付を生成する必要がある場合（ TZIDパラメータを指定）、次のようになります。非常に不正確な結果。 「UTC日付」を使用しているのは、UTCでDST計算を行っているためではなく（テストスイートを調べて、正しいDST計算の例をたくさん見ることができます）、JavaScript仕様のタイムゾーンがひどいためです。壊れており、UTCは利用可能な「ニュートラル」な日付の概念に最も近いものです。 作業が混乱し、このライブラリの使用法をこれ以上明確にできないことをお詫び申し上げます（ただし、提案は受け付けています）。

懸念しているのは、あなたが提起するブラウザの互換性の問題です。 実行中のNodeコンソール、またはFirefoxで独自のサンプルコードを試してみてください。 非常に異なる（そして正しい）結果が表示されます。

したがって、ここでの本当の問題は、結果がChromeで混乱することです。 対処する価値があると思いますが、その方法はすぐにはわかりません。 私があなたに言うことができるのは、両方の環境がまったく同じISO文字列とタイムスタンプを生成するということです。

@davidgoliそうです、Firefoxは、元のコードを実行すると、コンソールに異なる結果を表示します。 ただし、結果は最終的に同じ時間になります。Firefoxでは結果がUTC時間で表されるのに対し、ChromeではAmerica/Denver時間（またはおそらくローカルタイムゾーン）で表されます。

私はあなたの与えられた「期待される」出力があなたが本当に期待しているものである理由を理解していないと思います。 それらの時間は正しくないように見えます。

正しいのは、指定された現地時間に各時間のTZオフセットを追加した場合の時間です。 その後、すべての時間は19:00になります。 これが、RRuleがUTCを扱う理由であり、UTCの使用がこの特定のバグとは何の関係もない理由です。

定期的なイベントごとに19：00UTCの時間が必要ない理由を説明しようと思います。

ユーザーが毎週水曜日の午後1時にAmerica/Denverタイムゾーンの特定の場所で繰り返しイベントをスケジュールしたいとします。 簡単に言うと、これは、1年のどの時期であっても、その場所で水曜日の午後1時になると、毎週水曜日の午後1時に同じイベントが発生することを期待していることを意味します。 午後12時ではなく、午後2時ではありません。 アメリカ/デンバー時間は常に午後1時。

ただし、rruleは、タイムゾーンが渡された場合でも、UTC時間に従って再発を解決しています。これにより、基本的に、「ああ、午後1時のアメリカ/デンバーは19:00と評価されます。したがって、19：00アメリカ/デンバーでは、一年中常に午後1時を参照する必要があります。 」しかし、それは真実ではありません。 2018年11月4日より前はそうですが、11月4日以降、アメリカ/デンバーは夏時間を廃止します。その時点で、 UTC時間19:00はアメリカ/デンバー時間の午後12:00に評価されます。 そのため、ユーザーには、イベントが午後1時ではなく午後12時に発生していると誤って通知されます。

言い換えると、午後1時のアメリカ/デンバーは夏時間であるかどうかに応じて19:00または20:00 UTCのいずれかになり、19：と言いたいので、rruleを使用して正しい再発を取得することはできません。 00は一年中正しい時間です。

rruleは、ほとんどのプログラマーが信じている神話に賛同しているように感じます。つまり、UTCは、日付と時刻を処理するときに常に正しいソリューションであるということです。 ただし、これが最善の解決策ではない特定のインスタンスがあり、このインスタンス（特定の場所で将来のイベントを繰り返す）はその1つです。

編集：理論的には、rruleがUTCで時刻を返すことは問題ありませんが、タイムゾーンが渡されると、それらの時刻は特定のタイムゾーンに対して正しいはずです。つまり、19：00UTCから20：00UTCに切り替わるはずです。ここで説明している例の場合、結果セットのいくつかのポイント。

Lemmeはここに戻ってきます-これはドキュメントの問題だと思います。

RRule_always_はJS「UTC」の日付を返します。 ただし、これは、これらの日付がUTC時刻を表すことを意図していることを意味するものではありません。 むしろ、唯一の選択肢であるローカル日付の制限により、このライブラリが実行している日付計算には、タイムゾーンオフセットが0のJS日付のみを使用できるという決定が下されました。 これには誤解を招く副作用があり、これらの時間は実際にはUTCでの時間を表しているように見えますが、実際にはTZIDパラメータで表されるタイムゾーンで解釈されることを意図しています。 したがって、たとえばFirefoxでは、意図された動作は、ライブラリが19:00を表す日付を返すことであり、その時刻をデンバー時刻にするように要求したため、デンバー時刻に対して正しいものになります。 この日付がUTC日付であると報告しているという事実を無視することを意味します。これは、JavaScriptで役立つ唯一の種類の日付だからです。 代わりに、このルールにはデンバーのタイムゾーンがあるという知識を使用して、19：00をデンバーの現地時間として解釈することを目的としています。

これは、ローカルマシンのゾーン外のタイムゾーンを使用している場合に明確になります。 たとえば、代わりにゾーン名America/New_YorkでRRuleを設定した場合、日付は17:00として返されます。これは、マシンのタイムゾーン（デンバー）が19の場合の現地時間であるためです。要求されたタイムゾーン（ニューヨーク）で：00。

JavaScriptには日付を特定のタイムゾーンに「固定」する方法がないため、何があっても常に正しい日付と時刻を表し、日付がUTCとして報告するという事実を破棄できます。 タイムゾーンがRRuleで使用される場合、それは実際には現地時間です。 これが、Firefoxが正しい現地時間を19:00として提供する理由です（その日付はUTCとして報告されますが、実際にはデンバー時間です）。

これは物事を明確にしますか？ 紛らわしく、直感的ではないことは理解していますが、理解すれば簡単に推論できるようになることを理解するのに十分簡単なことを願っています。 私たちは間違いなくこれをよりよく文書化する必要があります。

これから探求したいことの1つは、Luxonを使用して、結果の日付をローカルタイムゾーンに再ゾーン化する可能性があるため、少なくとも期待と一致していることです。 これはそれほど難しいことではなく、このような誤解を明らかにするのに役立つはずだと思います。 Chromeの問題は私にとってまったく新しいものであり、悪いニュースです。

ただし、これは重大な変更となるため、出荷前にコミュニティからのフィードバックの機会を提供したいと思います。

@shorlbeckこの差分は、期待する動作を実装していると思います。

diff --git a/src/datewithzone.ts b/src/datewithzone.ts
index 8ae3ed0..d9b917c 100644
--- a/src/datewithzone.ts
+++ b/src/datewithzone.ts
@@ -38,7 +38,10 @@ export class DateWithZone {

       const rezoned = datetime.setZone(this.tzid!, { keepLocalTime: true })

-      return rezoned.toJSDate()
+      return rezoned
+        .toUTC()
+        .setZone('local', { keepLocalTime: true })
+        .toJSDate()
     } catch (e) {
       if (e instanceof TypeError) {
         console.error('Using TZID without Luxon available is unsupported. Returned times are in UTC, not the requested time zone')
diff --git a/test/rrule.test.ts b/test/rrule.test.ts
index 7774b8a..a794e02 100644
--- a/test/rrule.test.ts
+++ b/test/rrule.test.ts
@@ -3804,4 +3804,17 @@ describe('RRule', function () {
     expect(() => rule.between(invalidDate, validDate)).to.throw('Invalid date passed in to RRule.between')
     expect(() => rule.between(validDate, invalidDate)).to.throw('Invalid date passed in to RRule.between')
   })
+
+  it('#300', () => {
+    const rule = RRule.fromString(
+      "DTSTART;TZID=America/Denver:20181101T190000;\n"
+      + "RRULE:FREQ=WEEKLY;BYDAY=MO,WE,TH;INTERVAL=1;COUNT=3"
+    )
+
+    expect(rule.all()).to.deep.equal([
+      DateTime.utc(2018, 11, 2, 1, 0, 0).toJSDate(),
+      DateTime.utc(2018, 11, 6, 2, 0, 0).toJSDate(),
+      DateTime.utc(2018, 11, 8, 2, 0, 0).toJSDate(),
+    ])
+  })
 })

しかし、私はこれがこのライブラリに行く方法であると完全に確信しているわけではありません。 クライアントのローカルタイムゾーンで解釈されることを常に意図した「フローティング」時間を返すというライブラリの一般的なアプローチを考えると（オフセットは0ですが）。 rruleによって返される日付に適切なゲッターはgetUTC*ゲッターです。したがって、たとえば、元の結果の各日付にgetUTCHours()を使用すると、次のようになります。 Chromeでも正しい時間。

ここでの正しい修正は、このライブラリの動作を変更することではなく、疑似「UTC」（実際には「フローティング」）のやや特異な使用法をより明確に文書化することであると私は考えています。 しかし、私はこれについて説得することはできます。

ユースケースの説明と手順を含むREADMEを更新しました。 ただし、この議論を続けることに興味があり、ライブラリの将来のバージョンでこの動作を変更する可能性があります。

返信と詳しい説明ありがとうございます。

残念ながら、私はこれ以上混乱したことはありません。

日付と時刻の操作は、それらの日時が実際にUTCまたは実際に現地時間である場合は十分に困難ですが、UTC時刻が実際にはUTC時刻ではない場合もあることを覚えておく必要があります。 今日はあなたが書いたものを理解しようと一日中過ごしましたが、結局のところ、それは完全に直感に反しているので、私はそれについて頭を悩ませることができません。

コードを見て「UTC」の日付が表示されると、それが実際にUTCなのか、疑似UTCなのか、特にChromeの問題を追加した場合は思い出せません。 それは私がコーディングすることをほとんど不可能にしている。 それは私のコードの可読性に対する私の信頼を台無しにしています。

これが私の質問です...元の例に戻ります...本当のUTCでは、 2018-11-01 19:00:00はアメリカ/デンバー時間の午後1時（13:00）を指します。 そして私の例では、午後1時のアメリカ/デンバーが私のイベントの正しい時間です。 しかし、UTCが真のUTCでない場合、 tzidパラメーターを使用するときにnew Date(Date.UTC(2018, 10, 1, 13, 0, 0))またはnew Date(Date.UTC(2018, 10, 1, 19, 0, 0))を渡す必要があるということですか？ （違いは13:00と19:00です）

疑似UTCが出て行くだけでなく入っていくのですか？ または、真のUTCは入りますが、疑似UTCは出ますか？ そして、どうすればこれを確実に覚えることができますか？

rruleは次のように指定されます。

DTSTART;TZID=America/Denver:20181101T190000
RRULE:FREQ=WEEKLY;BYDAY=MO,WE,TH;INTERVAL=1;COUNT=7

ただし、RRULE RFC5545によると、これは、現地時間が1900であるデンバータイムゾーンのルールを示しています。https ：//tools.ietf.org/html/rfc5545#section -3.3.5

For example, the following represents 2:00 A.M. in New York on January 19, 1998:

       TZID=America/New_York:19980119T020000

デンバーの現地時間1300でDTSTARTが必要な場合は、ルールで1300として指定する必要があります。 ライブラリは、その点で仕様に完全に準拠している必要があります。 （まあ、それが1300 UTCを返すというマイナーな事実を除いて...）

さらに、「フローティング時間」のセクションを必ずお読みください。

FORM #1: DATE WITH LOCAL TIME

      The date with local time form is simply a DATE-TIME value that
      does not contain the UTC designator nor does it reference a time
      zone.  For example, the following represents January 18, 1998, at
      11 PM:

       19980118T230000

      DATE-TIME values of this type are said to be "floating" and are
      not bound to any time zone in particular.  They are used to
      represent the same hour, minute, and second value regardless of
      which time zone is currently being observed.  For example, an
      event can be defined that indicates that an individual will be
      busy from 11:00 AM to 1:00 PM every day, no matter which time zone
      the person is in.  In these cases, a local time can be specified.

残念ながら、JavaScriptは「浮動時間」の実装を提供していません。 「純粋な」タイムゾーンのない時間に最も近いオプションはUTC、つまり「psuedo-UTC」です。 （記録として、 rruleは浮動時間もサポートしており、TZIDでもZ UTC指定子でも指定されていません。）

UTCへの切り替えは、このコミットで完全に開始されました： https ：//github.com/jakubroztocil/rrule/commit/850ed075175eb1acfcbd7b2cddf0606f2b2206f7

前のコミットをチェックアウトし、＃850ed075から追加されたテストを選択すると、失敗することがわかります。 実際、スイート全体がUTCで実行されない限り、何百ものテストが失敗していました。 これは、DSTの境界を越える将来の日付を計算するために、現在の時計がDSTで実行されている日付をインスタンス化してから、標準時間に入る計算を計算する必要があり、1時間のオフセットが正しくないためです。 現在の実装では、常に正しい現地時間が得られます。 これで、テストスイート全体が実際にはどのローカル環境でも合格しますが、正しい日付/時間を取得するには、 getUTCDate() / getUTCHour()メソッドを使用する必要があることに注意してください。

将来のバージョンでこれを変更することを検討していますが、Luxonのような必須のサードパーティライブラリを採用しない限り、変更は簡単ではありません。

今後のバージョンでは、動作を変更して、ローカルタイムゾーンで常に正しい日付を返すようにしたいと思います。たとえば、次のようになります。

• DTSTART;TZID=America/Denver:20181101T130000は、デンバーにいる場合は1300-0700 （標準時）、UTCにいる場合は2000Zの日付を返します。
• DTSTART=20181101T130000は、デンバーにいる場合は1300-0700になり、UTCにいる場合は1300Zになります。
• DTSTART=20181101T130000Zは、デンバーにいる場合は0600-0700になり、UTCにいる場合は1300Zになります。

これはあなたが期待している振る舞いですか？

大きな問題の1つは、特定のローカルJS環境が単一のタイムゾーンの日付しか表現できないことです。 したがって、特定のタイムゾーン（現在のタイムゾーンとは異なる場合があります）の日時を表す場合は、 new Date(...)もnew Date(Date.UTC(...))も適切ではありません。

では、次のような動作が想定されています。

new RRule({
  dtstart: new Date(2018, 10, 1, 10, 0, 0),
  tzid: 'America/Denver'
})

ローカルマシンがAmerica/Los_Angelesにある場合は？ 作成している時間とその時間を希望するタイムゾーンとの1時間の違いを少なくともある程度認識している必要があります。したがって、午前11時（デンバー時間、要求されたゾーン）または午前10時（要求されたゾーン）を表すことになっています。ロサンゼルス時間、発信ゾーン）？ どちらかを主張できると思います。

ちなみに、 Dateオブジェクトは、タイムゾーンやオフセットの概念がないUTCミリ秒単位のタイムスタンプを表すという点で、ISO日付文字列とDTSTART文字列の両方とは異なります。 したがって、目的の時刻のタイムスタンプを_正しいゾーンで_表すのが最も理にかなっていると思います。つまり、ロサンゼルスにいて、デンバーで時刻を表したい場合は、相対で初期化されたDateオブジェクトを渡す必要があります。オフセットが適用されます（したがって、上記の例はデンバーの午前11時を表します）。 ただし、これは紛らわしいです。ニューヨークに旅行して同じ時間を代表したい場合は、 new Date(2018, 10, 1, 13, 0, 0)と書く必要があるからです。

ローカル日付の概念全体をウィンドウの外に出すことの利点は、これに対処する必要がないことです。 表示される日付と時刻は浮動時間として扱うことができ、変換を行わずに任意のタイムゾーンに投影できます。

もちろん、これはChromeのようなエンジンの動作によって複雑になります。

あなたの目的のために、あなたはおそらくあなたがすることによってあなたが望む値を得ることができます：

rule.all().map(d => new Date(
    d.getUTCFullYear(),
    d.getUTCMonth(),
    d.getUTCDate(),
    d.getUTCHours(),
    d.getUTCMinutes(),
    d.getUTCMilliseconds()
  ))

私は現在、これが適切なライブラリに属しているかどうかを判断しようとしています...

ありがとう！ あなたの回答は私にとって本当に明確なものでした。 昨日、すべてを理解しようとしていたとき、私は疲れて燃え尽きていたと思います。 私は今何が起こっているのかを見て、あなたが正しいです、私はtzidパラメータを使用するときに間違った時間を渡していました。

あなたの目的のために、あなたはおそらくあなたがすることによってあなたが望む値を得ることができます：

rule.all().map(d => new Date(
    d.getUTCFullYear(),
    d.getUTCMonth(),
    d.getUTCDate(),
    d.getUTCHours(),
    d.getUTCMinutes(),
    d.getUTCMilliseconds()
  ))

私は現在、これが適切なライブラリに属しているかどうかを判断しようとしています...

これは私のために働いた！ 本当にありがとう。 rule.all()とrule.between()によって返されるものを構成する方法があれば、それは素晴らしいことです。そうすれば、さらに別の重大な変更を導入することはありませんが、上記の動作をネイティブに取得できます。 rrulestr()またはRRule.fromString()を使用したいが、返される日付のタイプを指定するための追加の引数などを使用することも考えている場合、それを実現する方法がわかりません。

更新：上記のd.getUTCMilliseconds()をd.getUTCSeconds()に変更する必要があります

したがって、私のシステムのタイムゾーンが要求されたタイムゾーンと同じである場合にソリューションは機能しますが、システムのタイムゾーンと異なる場合に、要求されたタイムゾーンの日付をRRuleに返す方法を理解しようとするとひどい時間があります。 要求されたタイムゾーンではなく、システムのタイムゾーンで表された日付を常に返します。 例：

1. OSシステムのタイムゾーンをAmerica/Denverに設定します
2. Chrome devtoolsコンソールで、次のように入力します。

RRule.fromString(
    "DTSTART;TZID=America/Denver:20181101T130000;\n"
    + "RRULE:FREQ=WEEKLY;BYDAY=MO,WE,TH;INTERVAL=1;COUNT=7"
).all().map(d => new Date(
    d.getUTCFullYear(),
    d.getUTCMonth(),
    d.getUTCDate(),
    d.getUTCHours(),
    d.getUTCMinutes(),
    d.getUTCSeconds()
));

結果は正しいです（私が期待/必要としているものに対して）：

(7) [Thu Nov 01 2018 13:00:00 GMT-0600 (Mountain Daylight Time), Mon Nov 05 2018 13:00:00 GMT-0700 (Mountain Standard Time), Wed Nov 07 2018 13:00:00 GMT-0700 (Mountain Standard Time), Thu Nov 08 2018 13:00:00 GMT-0700 (Mountain Standard Time), Mon Nov 12 2018 13:00:00 GMT-0700 (Mountain Standard Time), Wed Nov 14 2018 13:00:00 GMT-0700 (Mountain Standard Time), Thu Nov 15 2018 13:00:00 GMT-0700 (Mountain Standard Time)]

1. OSシステムのタイムゾーンをAmerica/New_Yorkに変更します
2. Chromedevtoolsコンソールで同じコマンドを実行します。

システムのタイムゾーンで表されるため、結果は異なります。

(7) [Thu Nov 01 2018 15:00:00 GMT-0400 (Eastern Daylight Time), Mon Nov 05 2018 15:00:00 GMT-0500 (Eastern Standard Time), Wed Nov 07 2018 15:00:00 GMT-0500 (Eastern Standard Time), Thu Nov 08 2018 15:00:00 GMT-0500 (Eastern Standard Time), Mon Nov 12 2018 15:00:00 GMT-0500 (Eastern Standard Time), Wed Nov 14 2018 15:00:00 GMT-0500 (Eastern Standard Time), Thu Nov 15 2018 15:00:00 GMT-0500 (Eastern Standard Time)]

しかし、結果がシステムのタイムゾーンや真のUTCではなく、 America/Denverの時間を表すようにしたいのです。 America/Denverに再ゾーン化するにはどうすればよいですか？ Luxonに慣れていないので、代わりにmoment()を試しました。

RRule.fromString(
    "DTSTART;TZID=America/Denver:20181101T130000;\n"
    + "RRULE:FREQ=WEEKLY;BYDAY=MO,WE,TH;INTERVAL=1;COUNT=7"
).all().map(d => moment(new Date(
    d.getUTCFullYear(),
    d.getUTCMonth(),
    d.getUTCDate(),
    d.getUTCHours(),
    d.getUTCMinutes(),
    d.getUTCSeconds()
)).tz('America/Denver').toDate());

しかし、これはニューヨーク時間中に同じことを返します。これは、 toDate()が即座にシステムのタイムゾーンに戻すためです（少なくともChromeでは）。

@shorlbeckお気づきの方もいらっしゃると思いますが、MDTとEDTの両方の結果はUTCで同じなので、私の質問は次のとおりです。浮動時間だけでなく、 TZIDパラメータを使用してもよろしいですか？ システムのタイムゾーンに関係なく常に13:00を生成する場合は、浮動時間（基本的には同じですが、$ DSTART;TZID=<timezone>:<datetime> ＃$ではなくDSTART:<datetime>を使用）をお勧めします。

13:00疑似UTCです。 Chromeの問題を回避したい場合でも、以前のコメントの方法を使用してローカルの日付に変換する必要があります。

@davidgoliああ、そうだね。 浮動時間/疑似UTCが実際にどのように機能するかを理解した後、実際にはtzidパラメーターが必要ないことに気づきませんでした。 つまり、上記の.map()ソリューションも必要ないということです。 あなたのコメントは私を正しい方向に向けました。 本当にありがとう。

これが私が長い間取り組んできた中で最も紛らわしいことではないと言ったら嘘をつくでしょうが、今は正しい方向に向かっていることを嬉しく思います。

必要なもの（タイムゾーンのないフローティング日付）の明示的な表現を使用することを検討しましたか？ UTCタイムゾーンでネイティブJS日付を使用し、ドキュメントでUTCであると主張することは、DSTのバグが発生するまで機能するため、非常に混乱します。

オブジェクトを提案します(year, month, day, hours?, minutes?, seconds?, milliseconds?) .toDate()メソッドを持つ「RRuleDate」と呼びましょう。

このRRuleDateは、 before() 、 after() 、 between() 、およびall()が返されるものであり、 before() 、 after()のみです。 between() 、およびdtstartオプションは、パラメーターとして受け入れる必要があります。