콘솔 경고가 표시됩니까? 예:

'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시이기 때문에 예상한 대로입니다. (이것은 PHP가 아니라 JavaScript이기 때문에 로컬 머신 시간대 또는 UTC 이외의 시간대에서는 Date 개체를 제공할 수 없으므로 UTC는 이 라이브러리가 항상 사용하는 것입니다.)

UTC 날짜가 아닌 현지(MST/MDT) 날짜가 표시된다는 사실이 약간 당황스럽습니다. 내가 아는 한, 이 라이브러리는 현재 UTC 날짜만 반환하도록 구성되어 있지만 이전에는 대신 현지 날짜를 반환하는 데 사용되었습니다.

콘솔 경고가 표시됩니까? 예:

'사용 가능한 Luxon 없이 TZID를 사용하는 것은 지원되지 않습니다. 반환된 시간은 요청한 시간대가 아니라 UTC입니다'

콘솔 경고가 없습니다. Luxon이 제대로 제공되는 것 같습니다.

시간대에 관해서는 Chrome devtools 콘솔 명령줄에서 직접 코드를 실행한 결과 MST/DST가 표시됩니다.

단계: Chrome 열기 --> RRule 및 Luxon이 제공된 페이지로 이동 --> Cmd+Opt+I --> "콘솔" 탭 --> 위 스니펫을 복사하여 맨 아래의 명령줄에 붙여넣기 --> Enter

이 라이브러리는 현재 UTC 날짜만 반환하도록 구성되어 있지만 이전에는 대신 현지 날짜를 반환하는 데 사용되었습니다.

이게 어느 버전에서 바뀌었는지 아세요? 왜 그런 변화가 일어나겠습니까? UTC 날짜 만 반환하면 실제로 이 일광 절약 시간제 불일치 가 발생 합니다! 항상 13:00 UTC에 발생하는 이벤트는 이벤트가 일광 절약 시간제 전환 전/후 다른 시간에 시작되도록 보장합니다. 이 변경 사항을 되돌리거나 일광 절약 시간제를 계산할 수 있는 다른 대체 방법을 제공해야 한다고 생각합니다. UTC는 매우 유용하지만 모든 상황에서 항상 올바른 접근 방식은 아닙니다. 되풀이되는 이벤트로 작업할 때는 일광 절약 시간제가 적용 되기 때문에 이벤트가 발생하는 특정 시간대를 고려해야 합니다.

실제로 Node.js에서와 Chrome에서 다른 동작을 얻습니다.

나는 당신의 주어진 "예상"출력이 왜 당신이 정말로 기대하는 것인지 이해할 수 없다고 말하고 싶습니다. 해당 시간이 잘못 표시됩니다.

올바른 것은_ 주어진 현지 시간에 각 시간에 대한 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:00 UTC 시간을 원하지 않는 이유를 설명하려고 합니다.

사용자가 매주 수요일 오후 1시에 America/Denver 시간대 의 특정 위치에서 반복되는 이벤트를 예약하려고 한다고 가정해 보겠습니다. 간단히 말해서, 연중 언제이건 상관없이 사용자는 매주 수요일 오후 1시 에 해당 위치에서 수요일 오후 1시에 동일한 이벤트가 발생하기를 기대합니다. 12시도 아니고 2시도 아니고 미국/덴버 시간의 경우 항상 오후 1시에 있습니다.

그러나 rrule은 timezone을 넘겨도 UTC 시간에 따라 재발을 해결합니다. 이렇게 하면 기본적으로 "오오오후 1시 America/Denver는 19:00 으로 평가합니다. 그러나 그것은 사실이 아닙니다. 2018년 11월 4일 이전은 사실이지만 11월 4일 이후 America/Denver는 일광 절약 시간제를 해제합니다. 이 시점에서 UTC 시간 19:00 은 이제 America/Denver 시간 12:00pm으로 평가됩니다 . 따라서 사용자는 이벤트가 오후 1시가 아니라 오후 12시에 발생한다고 잘못 알고 있습니다.

즉, 1pm America/Denver는 일광 절약 시간제인지 여부에 따라 19:00 또는 20:00 UTC가 될 수 있으며 19:00라고 말하고 싶기 때문에 올바른 반복을 얻기 위해 rrule을 사용하는 것은 불가능합니다. 00은 연중 내내 정확한 시간입니다.

나는 rrule이 대부분의 프로그래머가 믿는 신화, 즉 UTC가 날짜와 시간을 다룰 때 항상 올바른 솔루션이라는 신화를 받아들이고 있다고 생각합니다. 그러나 이것이 최선의 솔루션이 아닌 특정 경우가 있으며 이 경우(특정 위치에서 미래의 이벤트 반복)가 그 중 하나입니다.

편집: 이론적으로 rrule이 UTC로 시간을 반환하는 것은 괜찮지만, 해당 시간은 시간대가 전달될 때 주어진 시간대에 대해 정확해야 합니다. 즉, 19:00 UTC가 20:00 UTC로 전환되는 것을 볼 수 있어야 합니다. 여기에서 논의되는 예의 경우 결과 집합의 특정 지점.

여기로 백업 - 문서화 문제라고 생각합니다.

RRule _always_는 JS "UTC" 날짜를 반환합니다. 그러나 그렇다고 해서 해당 날짜가 UTC 시간을 나타내는 것은 아닙니다. 오히려, 유일한 대안인 현지 날짜의 제한으로 인해 이 라이브러리가 수행하는 날짜 계산에 시간대 오프셋이 0인 _only_ JS 날짜를 사용할 수 있다는 결정이 내려졌습니다. 이것은 이러한 시간이 실제로 UTC의 시간을 나타내는 것처럼 보이지만 실제로는 TZID 매개변수로 표시되는 시간대에서 해석되어야 한다는 잘못된 부작용이 있습니다. 예를 들어 Firefox에서 의도한 동작은 라이브러리가 19:00을 나타내는 Date를 반환하고 해당 시간을 Denver 시간으로 요청했기 때문에 Denver 시간에 맞도록 하는 것입니다. JavaScript에서 유용한 유일한 종류의 날짜이기 때문에 이 날짜가 UTC 날짜라고 보고한다는 사실을 무시해야 합니다. 대신 이 규칙에 Denver 시간대가 있다는 지식을 사용하여 19:00을 Denver의 현지 시간으로 해석해야 합니다.

이것은 로컬 시스템 영역 외부의 시간대를 사용할 때 더 명확합니다. 예를 들어, 대신 America/New_York 영역 이름으로 RRule을 설정하면 날짜가 17:00으로 반환되는 것을 볼 수 있습니다. 이것은 19일 때 컴퓨터의 시간대(Denver)에서 현지 시간이기 때문입니다. :00 요청한 시간대(뉴욕).

JavaScript는 날짜를 특정 시간대에 "고정"할 방법이 없으므로 어떤 경우에도 항상 정확한 날짜와 시간을 나타내므로 Date가 자체적으로 UTC로 보고한다는 사실을 무시할 수 있습니다. RRule에서 시간대를 사용하는 경우 실제로는 현지 시간입니다. 이것이 Firefox가 정확한 현지 시간을 19:00으로 제공하는 이유입니다(해당 날짜가 UTC로 보고되지만 실제로는 Denver 시간입니다).

이것이 모든 것을 명확히 합니까? 나는 그것이 혼란스럽고 직관적이지 않다는 것을 이해하지만, 일단 이해되면 추론하기 쉬워진다는 것을 이해할만큼 간단하기를 바랍니다. 우리는 확실히 이것을 더 잘 문서화해야 합니다.

이것에서 내가 탐구하고 싶은 한 가지는 Luxon을 사용하여 결과 날짜를 현지 시간대로 조정할 수 있다는 것입니다. 따라서 최소한 귀하의 기대와 일치합니다. 나는 이것이 너무 어렵지 않아야하며 이와 같은 오해를 명확히하는 데 도움이되어야한다고 생각합니다. Chrome 문제는 나에게 진정으로 새로운 것이며 나쁜 소식입니다.

그러나 이것은 주요 변경 사항이므로 배송하기 전에 커뮤니티 피드백을 위한 기회를 제공하고 싶습니다.

@shorlbeck 이 diff는 다음과 같이 예상되는 동작을 구현한다고 생각합니다.

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 에서 반환된 날짜에 대한 적절한 getter는 getUTC* getter이므로 예를 들어 원래 결과의 각 날짜에 getUTCHours() 를 사용하면 Chrome에서도 정확한 시간을 확인할 수 있습니다.

여기서 올바른 수정은 이 라이브러리의 동작을 변경하는 것이 아니라 의사 "UTC"(실제로는 "플로팅") 시간의 다소 특이한 사용법을 더 명확하게 문서화하는 것이라고 생각하는 쪽으로 기울고 있습니다. 그러나 나는 이것에 대해 설득력이 있습니다.

귀하의 사용 사례에 대한 몇 가지 설명과 지침으로 README를 업데이트했습니다. 그러나 이 논의를 계속하는 데 관심이 있으며 향후 라이브러리 버전에서 이 동작을 변경할 가능성이 있습니다.

답변과 자세한 설명 감사합니다.

불행히도, 나는 결코 더 혼란스러워하지 않았습니다.

날짜와 시간으로 작업하는 것은 날짜 시간이 실제로 UTC이거나 실제로 현지 시간일 때 충분히 어렵지만 때때로 UTC 시간이 실제로 UTC 시간이 아니라는 것을 기억해야 하는 것은 내 두뇌가 처리할 수 있는 것 이상입니다. 나는 오늘 하루 종일 당신이 쓴 것을 이해하려고 노력했지만 하루가 끝나면 완전히 반직관적이어서 내 마음을 감쌀 수 없습니다.

코드를 볼 때마다 "UTC" 날짜가 표시될 때마다 그것이 실제로 UTC 인지 그냥 의사 UTC인지 기억할 수 없습니다. 특히 거기에 Chrome 문제를 추가할 때 그렇습니다. 그것은 내가 코딩하는 것을 거의 불가능하게 만듭니다. 그것은 내 코드의 가독성에 대한 나의 신뢰를 망치고 있습니다.

여기 내 질문이 있습니다. 그러면... 원래의 예로 돌아가서... 실제 UTC에서 2018-11-01 19:00:00 는 미국/덴버 시간(13:00)의 오후 1시를 나타냅니다. 그리고 제 예에서는 오후 1시 America/Denver가 제 이벤트의 정확한 시간입니다. 그러나 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 vs. 19:00)

의사 UTC가 들어오고 나가는 것입니까? 아니면 실제 UTC가 들어가고 의사 UTC가 나오나요? 그리고 어떻게 이것을 확실하게 기억할 수 있습니까??

규칙은 다음과 같이 지정됩니다.

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

그러나 RRULE RFC5545에 따르면 이것은 현지 시간이 1900인 Denver 시간대의 규칙을 나타냅니다. 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 현지 Denver 시간에 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 입니다.

이것이 당신이 기대하는 행동입니까?

한 가지 큰 문제는 주어진 로컬 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시(Denver 시간, 요청한 영역) 또는 오전 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. Chrome devtools 콘솔에서 동일한 명령을 실행합니다.

결과는 시스템 시간대에 표시되기 때문에 다릅니다.

(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() 솔루션도 필요하지 않습니다. 귀하의 의견은 올바른 방향으로 나를 지적했습니다. 정말 고마워.

이것이 내가 오랫동안 작업한 것 중 가장 혼란스러운 일이 아니었다면 거짓말이겠지만, 지금은 올바른 방향으로 가고 있어 기쁩니다.

필요한 것을 명시적으로 표현하는 것을 고려했습니까(시간대 없는 부동 날짜)? 기본 JS Date를 UTC 시간대 와 함께 사용하고 문서에서 UTC라고 주장하는 것은 DST 버그가 발생할 때까지 작동하기 때문에 매우 혼란스럽습니다.

(year, month, day, hours?, minutes?, seconds?, milliseconds?) 생성자를 사용하고 .toDate() 메서드가 있는 "RRuleDate"라고 하는 개체를 제안하겠습니다.

이 RRuleDate는 before() , after() , between() 및 all() 가 반환되어야 하는 항목이며 before() , after() , between() 및 dtstart 옵션은 매개변수로 허용되어야 합니다.