क्या आपको कोई कंसोल चेतावनियां मिल रही हैं? उदाहरण:

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

लक्सॉन optionalDependencies में है, इसलिए इसे आयात किया जाएगा यदि यह आपके node_modules में है लेकिन अन्यथा नहीं।

जब मैं आपका कोड रूल टेस्ट सूट में चलाता हूं, तो मुझे मिलता है:

      [
        [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 नहीं है, हम आपको आपके स्थानीय मशीन टाइमज़ोन या यूटीसी के अलावा किसी अन्य टाइमज़ोन में Date ऑब्जेक्ट नहीं दे सकते हैं, इसलिए यूटीसी वह है जो यह लाइब्रेरी हर समय उपयोग करती है।)

तथ्य यह है कि आप स्थानीय (एमएसटी/एमडीटी) तिथियां देख रहे हैं, न कि यूटीसी तिथियां मेरे लिए थोड़ा चौंकाने वाली हैं। जहां तक ​​​​मुझे पता है, यह पुस्तकालय वर्तमान में केवल यूटीसी तिथियों को वापस करने के लिए कॉन्फ़िगर किया गया है, हालांकि यह पहले स्थानीय तिथियों को वापस करने के लिए उपयोग किया जाता था।

क्या आपको कोई कंसोल चेतावनियां मिल रही हैं? उदाहरण:

'लक्सॉन उपलब्ध के बिना TZID का उपयोग करना असमर्थित है। लौटाया गया समय यूटीसी में है, अनुरोधित समय क्षेत्र नहीं'

कोई कंसोल चेतावनी नहीं। ऐसा प्रतीत होता है कि लक्सन ठीक से प्रदान किया गया है।

जहाँ तक टाइमज़ोन की बात है, मुझे अपना कोड सीधे Chrome devtools कंसोल कमांड लाइन में चलाने के परिणामस्वरूप MST/DST मिलता है।

चरण: क्रोम खोलें -> RRule और Luxon के साथ पेज पर नेविगेट करें -> Cmd+Opt+I -> "Console" tab -> ऊपर दिए गए स्निपेट को नीचे कमांड लाइन में कॉपी और पेस्ट करें -> एंटर करें

यह पुस्तकालय वर्तमान में केवल यूटीसी तिथियों को वापस करने के लिए कॉन्फ़िगर किया गया है, हालांकि यह पहले स्थानीय तिथियों को वापस करने के लिए उपयोग किया जाता था।

क्या आप जानते हैं कि यह किस संस्करण में बदल गया? वह बदलाव क्यों किया जाएगा? केवल UTC तिथियों को लौटाना वास्तव में इस दिन के उजाले की बचत विसंगति का परिचय देता है! एक घटना जो हमेशा 13:00 यूटीसी पर होती है, इस बात की बहुत अधिक गारंटी देता है कि घटना दिन के उजाले बचत स्विच से पहले/बाद में एक अलग समय पर शुरू होगी। मुझे लगता है कि इस परिवर्तन को वापस ले लिया जाना चाहिए, अन्यथा कोई अन्य वैकल्पिक तरीका प्रदान किया जाना चाहिए जिससे डेलाइट सेविंग्स का हिसाब लगाया जा सके। यूटीसी अत्यंत उपयोगी है लेकिन यह सभी स्थितियों में हमेशा सही दृष्टिकोण नहीं होता है। आवर्ती घटनाओं के साथ काम करते समय हमें उस विशिष्ट समय क्षेत्र को ध्यान में रखना होगा जिसमें घटना विशेष रूप से होती है क्योंकि दिन के उजाले की बचत एक चीज है।

दरअसल, मुझे क्रोम से अलग व्यवहार मिलता है, जैसा कि मैं नोड से करता हूं।

मैं कहूंगा कि मुझे समझ में नहीं आता कि आपका दिया गया "अपेक्षित" आउटपुट वह है जो आप वास्तव में उम्मीद कर रहे हैं। वे समय गलत दिखाई देते हैं।

यदि आप दिए गए स्थानीय समय में हर बार 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 स्ट्रिंग्स को लगातार सही दिनांक और समय के साथ देखेंगे।

इसके अलावा, ऐसा प्रतीत होता है कि क्रोम यूटीसी में तारीखों को वापस करने का समर्थन नहीं करता है:

> 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 का उपयोग करता है, न कि केवल आपके स्थानीय समयक्षेत्र के लिए। यही कारण है कि यूटीसी का उपयोग महत्वपूर्ण है: यदि टाइमज़ोन कोड आपके स्थानीय टाइमज़ोन के लिए "सही" तिथियां लौटाता है, लेकिन आपको एक अलग टाइमज़ोन ( TZID परम के साथ दिया गया) में तिथियां उत्पन्न करने की आवश्यकता होती है, तो आपको मिलेगा बेतहाशा गलत परिणाम। हम "यूटीसी तिथियों" का उपयोग नहीं कर रहे हैं क्योंकि हम यूटीसी में डीएसटी गणित कर रहे हैं (हम नहीं हैं, आप परीक्षण सूट का निरीक्षण कर सकते हैं और सही डीएसटी गणनाओं के बहुत सारे उदाहरण देख सकते हैं), लेकिन क्योंकि जावास्क्रिप्ट स्पेक में टाइमज़ोन बहुत ही भयानक हैं टूटा हुआ है, और यूटीसी उपलब्ध "तटस्थ" तिथि अवधारणा के सबसे करीब है। मुझे खेद है कि इसके साथ काम करना भ्रमित करने वाला है और इस पुस्तकालय का इसका उपयोग अधिक स्पष्ट नहीं हो सकता है (हालांकि मैं सुझावों के लिए खुला हूं)।

आपके द्वारा लाए जाने वाले ब्राउज़र संगतता समस्या से संबंधित _is_ क्या है। मैं आपसे अब चल रहे नोड कंसोल में, या उस मामले के लिए फ़ायरफ़ॉक्स में अपना स्वयं का नमूना कोड आज़माने के लिए कहूँगा। आप बहुत अलग (और सही) परिणाम देखेंगे।

तो यहां असली मुद्दा यह है कि परिणाम क्रोम में भ्रमित कर रहे हैं। मुझे लगता है कि यह संबोधित करने लायक है, हालांकि यह मुझे तुरंत स्पष्ट नहीं है कि ऐसा कैसे करें। जो मैं _can_ आपको बताता हूं वह यह है कि दोनों वातावरण एक ही आईएसओ स्ट्रिंग और टाइमस्टैम्प उत्पन्न करते हैं।

@davidgoli आप सही कह रहे हैं, मेरा मूल कोड चलाते समय फ़ायरफ़ॉक्स कंसोल में एक अलग परिणाम दिखाता है। हालांकि, परिणाम अंततः एक ही समय है, यह सिर्फ इतना है कि परिणाम फ़ायरफ़ॉक्स में यूटीसी समय में व्यक्त किया जाता है जबकि क्रोम में इसे America/Denver समय (या शायद आपका स्थानीय समय क्षेत्र जो भी हो) में व्यक्त किया जाता है।

मैं कहूंगा कि मुझे समझ में नहीं आता कि आपका दिया गया "अपेक्षित" आउटपुट वह है जो आप वास्तव में उम्मीद कर रहे हैं। वे समय गलत दिखाई देते हैं।

क्या सही होगा वह समय जब आप दिए गए स्थानीय समय में हर बार TZ ऑफ़सेट जोड़ते हैं। तब सभी समय 19:00 बजे होंगे। यही कारण है कि RRule UTC में डील करता है, और क्यों UTC के इसके उपयोग का इस विशेष बग से कोई लेना-देना नहीं है।

मुझे यह समझाने का प्रयास करें कि हम प्रत्येक पुनरावर्ती घटना के लिए 19:00 UTC समय क्यों नहीं चाहते हैं।

मान लें कि कोई उपयोगकर्ता किसी विशिष्ट स्थान पर America/Denver टाइमज़ोन में प्रत्येक बुधवार को दोपहर 1 बजे किसी विशिष्ट स्थान पर दोहराए जाने वाले ईवेंट को शेड्यूल करना चाहता है। सीधे शब्दों में कहें तो इसका मतलब है - चाहे वह साल का कोई भी समय क्यों न हो - उपयोगकर्ता को हर बुधवार को दोपहर 1 बजे जब भी बुधवार को दोपहर 1 बजे उस स्थान पर इसी तरह की घटना होने की उम्मीद होती है। दोपहर 12 बजे नहीं, दोपहर 2 बजे नहीं। अमेरिका/डेनवर समय के लिए हमेशा दोपहर 1 बजे।

हालांकि, नियम यूटीसी समय के अनुसार पुनरावृत्ति का समाधान कर रहा है -- यहां तक ​​कि जब एक समयक्षेत्र पारित किया जाता है। ऐसा करने से, यह मूल रूप से कह रहा है, "ओह, 1:00 बजे अमेरिका/डेनवर का मूल्यांकन 19:00 है। इसलिए, 19:00 पूरे साल अमेरिका/डेनवर में हमेशा दोपहर 1:00 बजे का उल्लेख करना चाहिए। " लेकिन यह सच नहीं है। 4 नवंबर, 2018 से पहले यह सच है, लेकिन 4 नवंबर के बाद, अमेरिका/डेनवर डेलाइट सेविंग टाइम बंद कर देता है, उस समय, 19:00 यूटीसी समय अब ​​12:00 बजे अमेरिका/डेनवर समय का मूल्यांकन करता है । तो हमारे उपयोगकर्ता को गलत तरीके से बताया जाता है कि घटना दोपहर 1 बजे नहीं बल्कि दोपहर 12 बजे हो रही है।

दूसरे शब्दों में, 1pm अमेरिका/डेनवर या तो 19:00 या 20:00 UTC हो सकता है, इस पर निर्भर करता है कि हम डेलाइट सेविंग टाइम पर हैं या नहीं, और सही पुनरावर्तन प्राप्त करने के लिए rrule का उपयोग करना असंभव है क्योंकि यह कहना चाहता है कि 19: 00 साल भर का सही समय है।

मुझे लगता है कि अधिकांश प्रोग्रामर का मानना ​​​​है कि नियम मिथक में खरीद रहा है, जो यह है कि तारीखों और समय से निपटने के दौरान यूटीसी हमेशा सही समाधान होता है। लेकिन ऐसे कुछ उदाहरण हैं जहां यह सबसे अच्छा समाधान नहीं है, और यह उदाहरण (किसी विशिष्ट स्थान पर भविष्य की घटनाओं को दोहराना) उनमें से एक है।

संपादित करें: सिद्धांत रूप में, मैं यूटीसी में समय वापस करने के नियम के साथ ठीक हूं, लेकिन वह समय दिए गए समय क्षेत्र के लिए सही होना चाहिए, जब एक समय क्षेत्र पारित हो जाता है। इसका मतलब है कि हमें 19:00 यूटीसी स्विच को 20:00 यूटीसी पर देखना चाहिए परिणाम सेट में कुछ बिंदु, उदाहरण के लिए यहां चर्चा की जा रही है।

Lemme यहाँ बैक अप - मुझे लगता है कि यह एक दस्तावेज़ीकरण समस्या है।

RRule _always_ JS "UTC" दिनांक लौटाता है। हालांकि, इसका मतलब यह नहीं है कि वे तिथियां यूटीसी समय का प्रतिनिधित्व करने के लिए हैं। बल्कि, एकमात्र विकल्प - स्थानीय तिथियों की सीमाओं के कारण - यह निर्णय लिया गया है कि 0 टाइमज़ोन ऑफ़सेट वाली _only_ JS तिथियां इस पुस्तकालय द्वारा किए जा रहे गणित के लिए उपयोग योग्य हैं। इसका भ्रामक साइड इफेक्ट है कि ऐसा प्रतीत होता है कि ये समय वास्तव में यूटीसी में समय का प्रतिनिधित्व करते हैं, जब वास्तव में उन्हें TZID परम द्वारा दर्शाए गए टाइमज़ोन में व्याख्या किया जाना है। तो उदाहरण के लिए, फ़ायरफ़ॉक्स में, इच्छित व्यवहार यह है कि पुस्तकालय आपको 19:00 का प्रतिनिधित्व करने वाली तिथि देता है, और, क्योंकि आपने उस समय को डेनवर समय होने के लिए कहा था, यह डेनवर समय के लिए सही होगा। आप इस तथ्य को अनदेखा करने के लिए हैं कि यह तिथि रिपोर्ट करती है कि यह एक यूटीसी तिथि है, क्योंकि यह एकमात्र ऐसी तिथि है जो जावास्क्रिप्ट में उपयोगी है। इसके बजाय, आप इस ज्ञान का उपयोग करने के लिए हैं कि इस नियम में 19:00 को डेनवर में स्थानीय समय के रूप में व्याख्या करने के लिए डेनवर समय क्षेत्र है।

यह तब स्पष्ट होता है जब आप अपने स्थानीय मशीन के क्षेत्र के बाहर टाइमज़ोन का उपयोग कर रहे होते हैं। उदाहरण के लिए, यदि आप इसके बजाय ज़ोन नाम America/New_York के साथ अपना RRule सेट करते हैं, तो आप देखेंगे कि दिनांक 17:00 के रूप में वापस आ गए हैं, क्योंकि यह आपकी मशीन के टाइमज़ोन (डेनवर) में स्थानीय समय है जब यह 19 है :00 अनुरोधित समय क्षेत्र (न्यूयॉर्क) में।

जावास्क्रिप्ट के पास किसी विशिष्ट समय क्षेत्र में किसी तिथि को "पिन" करने का कोई तरीका नहीं है, इसलिए हम हमेशा सही तिथि और समय का प्रतिनिधित्व करते हैं, चाहे कुछ भी हो, और आप इस तथ्य को त्याग सकते हैं कि तिथि स्वयं को यूटीसी के रूप में रिपोर्ट करती है। जब RRule में टाइमज़ोन का उपयोग किया जाता है, तो यह वास्तव में एक स्थानीय समय होता है। यही कारण है कि फ़ायरफ़ॉक्स आपको 19:00 के रूप में सही स्थानीय समय देता है (भले ही उस तिथि को यूटीसी के रूप में रिपोर्ट किया गया हो, यह वास्तव में डेनवर समय है)।

क्या यह चीजों को बिल्कुल स्पष्ट करता है? मैं समझता हूं कि यह भ्रमित करने वाला है और सहज ज्ञान युक्त नहीं है, लेकिन उम्मीद है कि यह समझने में काफी आसान है कि एक बार इसे समझने के बाद इसके बारे में तर्क करना आसान हो जाता है। हमें निश्चित रूप से इसका बेहतर दस्तावेजीकरण करना चाहिए।

एक चीज जो मैं इससे तलाशना चाहता हूं, वह है लक्सॉन का उपयोग करके परिणामी तिथियों को स्थानीय समय क्षेत्र में फिर से जोड़ना, इसलिए यह कम से कम आपकी अपेक्षाओं के अनुरूप है। मुझे लगता है कि यह बहुत कठिन नहीं होना चाहिए, और इस तरह की गलतफहमी को स्पष्ट करने में मदद करनी चाहिए। क्रोम मुद्दा वास्तव में मेरे लिए नया है, और यह बुरी खबर है।

हालांकि, यह एक महत्वपूर्ण बदलाव होगा, इसलिए मैं शिपिंग से पहले समुदाय प्रतिक्रिया के लिए अवसर प्रदान करना चाहता हूं।

@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() का उपयोग करते हैं, तो आपको मिलेगा सही घंटे, यहां तक ​​कि क्रोम में भी।

मैं इस पुस्तकालय के व्यवहार को बदलने के लिए नहीं, बल्कि छद्म- "यूटीसी" (वास्तव में "फ्लोटिंग") के कुछ हद तक मूर्खतापूर्ण उपयोग को दस्तावेज करने के लिए सही फिक्स सोचने की ओर झुका रहा हूं। हालांकि, मैं इस पर राजी करने के लिए तैयार हूं।

मैंने आपके उपयोग के मामले के लिए कुछ स्पष्टीकरण और निर्देशों के साथ रीडमे को अपडेट किया है। हालांकि, मुझे इस चर्चा को जारी रखने में दिलचस्पी है, और पुस्तकालय के भविष्य के संस्करण में संभवतः इस व्यवहार को बदलने के लिए खुला हूं।

उत्तर और विस्तृत स्पष्टीकरण के लिए धन्यवाद।

दुर्भाग्य से, मैं कभी अधिक भ्रमित नहीं हुआ।

दिनांक और समय के साथ कार्य करना काफी कठिन होता है जब वे दिनांक समय या तो वास्तव में यूटीसी या वास्तव में स्थानीय समय होते हैं, लेकिन यह भी याद रखना चाहिए कि कभी-कभी यूटीसी समय वास्तव में यूटीसी समय नहीं होता है जो मेरे दिमाग से अधिक होता है। मैंने आज पूरा दिन यह समझने में बिताया है कि आपने क्या लिखा है, लेकिन अंत में, यह इतना उल्टा है कि मैं अपने दिमाग को इसके चारों ओर लपेट नहीं सकता।

जब भी मैं कोड को देखता हूं और मुझे "यूटीसी" तिथि दिखाई देती है तो मुझे याद नहीं आता कि यह वास्तव में यूटीसी है या सिर्फ छद्म-यूटीसी है, खासकर जब आप वहां क्रोम समस्या जोड़ते हैं। यह मेरे लिए कोड करना लगभग असंभव बना रहा है। यह मेरे कोड की पठनीयता में मेरा विश्वास बर्बाद कर रहा है।

यहाँ मेरा प्रश्न है, फिर... अपने मूल उदाहरण पर वापस जा रहे हैं... सही UTC में, 2018-11-01 19:00:00 अमेरिका/डेनवर समय (13:00) में दोपहर 1 बजे को संदर्भित करता है। और मेरे उदाहरण में, दोपहर 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 है)

क्या यह छद्म-यूटीसी अंदर जा रहा है और बाहर भी आ रहा है? या सच यूटीसी अंदर जा रहा है लेकिन छद्म यूटीसी बाहर आ रहा है? और मैं इसे कभी भी मज़बूती से कैसे याद रख सकता हूँ ??

आपका नियम इस प्रकार निर्दिष्ट है:

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 यूटीसी लौटाएगा ...)

इसके अतिरिक्त, "फ्लोटिंग टाइम" पर अनुभाग पढ़ना सुनिश्चित करें:

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.

जावास्क्रिप्ट, दुर्भाग्य से, "फ्लोटिंग टाइम" के कार्यान्वयन की पेशकश नहीं करता है। हमारे पास "शुद्ध" का निकटतम विकल्प है, समय क्षेत्र-रहित समय यूटीसी है, इसलिए "छद्म-यूटीसी"। (रिकॉर्ड के लिए, rrule फ्लोटिंग समय का भी समर्थन करता है, न तो TZID और न ही Z UTC डिज़ाइनर के साथ निर्दिष्ट।)

इस कमिटमेंट के साथ UTC पर स्विच पूरी तरह से शुरू हो गया था: https://github.com/jakubroztocil/rrule/commit/850ed075175eb1acfcbd7b2cddf0606f2b2206f7

यदि आप पिछली प्रतिबद्धता की जांच करते हैं, और #850ed075 से जोड़ा गया परीक्षण चेरी-चुनते हैं, तो आप इसे असफल देखेंगे। वास्तव में, सैकड़ों परीक्षण विफल हो रहे थे जब तक कि संपूर्ण सुइट UTC में नहीं चला। ऐसा इसलिए है, क्योंकि भविष्य की तारीखों की गणना करने के लिए, जो डीएसटी की सीमाओं के पार हैं, हमें उन तारीखों को तत्काल करना था जब वर्तमान घड़ी डीएसटी में चल रही थी और फिर गणित की गणना करें जो हमें मानक समय में डाल देती है, जिसके परिणामस्वरूप गलत 1-घंटे की ऑफसेट होती है। वर्तमान कार्यान्वयन हमेशा सही स्थानीय समय देता है। अब, संपूर्ण परीक्षण सूट वास्तव में किसी भी स्थानीय वातावरण में पारित होगा, इस चेतावनी के साथ कि सही तिथि/घंटा प्राप्त करने के लिए आपको getUTCDate() / getUTCHour() विधियों का उपयोग करना होगा।

मैं भविष्य के संस्करण में इसे बदलने की जांच कर रहा हूं, लेकिन लक्सन जैसी आवश्यक तृतीय पक्ष लाइब्रेरी को अपनाने के बिना परिवर्तन छोटा नहीं है।

आने वाले संस्करण में मैं आपके स्थानीय समय क्षेत्र में हमेशा सही तारीखों को वापस करने के लिए व्यवहार को बदलना पसंद करूंगा, उदाहरण के लिए:

• यदि आप डेनवर में हैं तो DTSTART;TZID=America/Denver:20181101T130000 आपको एक तारीख लौटाएगा जो 1300-0700 (मानक समय) है, या यदि आप यूटीसी में हैं तो 2000Z
• यदि आप डेनवर में हैं तो DTSTART=20181101T130000 आपको 1300-0700 और यदि आप UTC में हैं तो 1300Z देंगे
• यदि आप डेनवर में हैं तो DTSTART=20181101T130000Z आपको 0600-0700 देगा, और यदि आप UTC में हैं तो 1300Z

क्या यह वह व्यवहार है जिसकी आप अपेक्षा कर रहे हैं?

एक बड़ी समस्या यह है कि किसी दिए गए स्थानीय जेएस पर्यावरण केवल एक ही समय क्षेत्र में तिथियों का प्रतिनिधित्व कर सकता है। इस प्रकार, न तो new Date(...) और न ही new Date(Date.UTC(...)) वास्तव में उपयुक्त है जब आप किसी विशिष्ट समय क्षेत्र में दिनांक-समय का प्रतिनिधित्व करना चाहते हैं (जो आपके वर्तमान समय क्षेत्र से भिन्न हो सकता है)।

तो व्यवहार क्या होना चाहिए:

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

यदि स्थानीय मशीन America/Los_Angeles में है? आपके द्वारा बनाए जा रहे समय और उस समय में आप जिस समय क्षेत्र में चाहते हैं, के बीच 1 घंटे के अंतर के बारे में आपको कम से कम कुछ जागरूक होना होगा। तो क्या यह 11am (डेनवर समय, अनुरोधित क्षेत्र) या 10am का प्रतिनिधित्व करना चाहिए ( लॉस एंजिल्स समय, मूल क्षेत्र)? मुझे लगता है कि आप दोनों के लिए मामला बना सकते हैं।

पैडेंटिक रूप से, एक Date ऑब्जेक्ट ISO दिनांक स्ट्रिंग और DTSTART स्ट्रिंग दोनों से अलग है, जिसमें यह UTC मिलीसेकंड में एक टाइमस्टैम्प का प्रतिनिधित्व करता है जिसमें टाइमज़ोन या ऑफ़सेट की कोई अवधारणा नहीं है। तो मुझे लगता है कि यह वांछित समय के टाइमस्टैम्प का प्रतिनिधित्व करने के लिए सबसे अधिक समझ में आता है _ सही क्षेत्र में _ जिसका अर्थ है कि यदि आप लॉस एंजिल्स में हैं और आप डेनवर में समय का प्रतिनिधित्व करना चाहते हैं, तो आपको रिश्तेदार के साथ शुरू की गई दिनांक वस्तु में पास करना होगा ऑफसेट लागू (इसलिए उपरोक्त उदाहरण डेनवर में सुबह 11 बजे का प्रतिनिधित्व करेगा)। हालांकि यह भ्रमित करने वाला है, क्योंकि यदि आप न्यूयॉर्क की यात्रा करते हैं और उसी समय का प्रतिनिधित्व करना चाहते हैं, तो आपको new Date(2018, 10, 1, 13, 0, 0) लिखना होगा!

स्थानीय तिथियों की पूरी अवधारणा को खिड़की से बाहर निकालने का एक फायदा यह है कि आपको इससे निपटने की ज़रूरत नहीं है; प्रतिनिधित्व की गई तिथि और समय को एक अस्थायी समय के रूप में माना जा सकता है, जो बिना किसी रूपांतरण के किसी भी समय क्षेत्र में प्रक्षेपित होने में सक्षम है।

बेशक, क्रोम जैसे इंजनों के व्यवहार से यह जटिल है।

अपने उद्देश्यों के लिए, आप संभवतः वे मान प्राप्त कर सकते हैं जो आप करना चाहते हैं:

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() . में बदला जाना चाहिए

तो, आपका समाधान तब काम करता है जब मेरे सिस्टम का टाइमज़ोन अनुरोधित टाइमज़ोन के समान होता है, लेकिन मुझे यह पता लगाने का एक भयानक समय हो रहा है कि आरआरयूएल को सिस्टम टाइमज़ोन से अलग होने पर अनुरोधित टाइमज़ोन में तारीखों को वापस करने के लिए कैसे प्राप्त किया जाए। यह हमेशा अनुरोधित समय क्षेत्र में प्रतिनिधित्व करने के बजाय सिस्टम टाइमज़ोन में दर्शाए गए दिनांक लौटाता है। उदाहरण:

1. अपने OS सिस्टम टाइमज़ोन को America/Denver . पर सेट करें
2. क्रोम देवटूल कंसोल में, दर्ज करें:

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)]

लेकिन मैं चाहता हूं कि परिणाम America/Denver समय का प्रतिनिधित्व करे, न कि मेरा सिस्टम टाइमज़ोन, न ही सही यूटीसी। मैं इसे America/Denver के रूप में कैसे पुन: ज़ोन कर सकता हूँ? मैं लक्सन से परिचित नहीं हूं इसलिए मैंने इसके बजाय 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() इसे तुरंत सिस्टम टाइमज़ोन (क्रोम में, कम से कम) में वापस रखता है।

@shorlbeck यदि आप ध्यान दें, एमडीटी और ईडीटी में परिणाम यूटीसी में समान हैं, तो मेरा प्रश्न है: क्या आप वाकई TZID परम का उपयोग करना चाहते हैं, न कि केवल फ़्लोटिंग समय? मैं फ़्लोटिंग समय की अनुशंसा करता हूं (मूल रूप से वही, लेकिन DSTART:<datetime> के बजाय DSTART;TZID=<timezone>:<datetime> के साथ) यदि आप चाहते हैं कि यह सिस्टम टाइमज़ोन की परवाह किए बिना हमेशा 13:00 उत्पन्न करे।

13:00 छद्म-यूटीसी यानी। यदि आप क्रोम समस्या को हल करना चाहते हैं, तो आपको अभी भी मेरी पूर्व टिप्पणी में विधि का उपयोग करके स्थानीय तिथि में कनवर्ट करना होगा।

@davidgoli ओह वाह, तुम सही हो। मुझे एहसास नहीं हुआ कि मुझे वास्तव में tzid परम की आवश्यकता नहीं है, जब मैं समझ गया कि फ़्लोटिंग टाइम/छद्म-यूटीसी वास्तव में कैसे काम करता है। और इसका मतलब है कि मुझे ऊपर दिए गए .map() समाधान की भी आवश्यकता नहीं है। आपकी टिप्पणी ने मुझे सही दिशा में इंगित किया। बहुत बहुत धन्यवाद।

मैं झूठ बोलूंगा अगर मैंने कहा कि यह सबसे भ्रमित करने वाली चीज नहीं है जिस पर मैंने लंबे समय तक काम किया है, लेकिन मुझे अभी सही दिशा में आगे बढ़ने में खुशी है।

क्या आपने अपनी आवश्यकता के स्पष्ट प्रतिनिधित्व का उपयोग करने पर विचार किया है (समयक्षेत्र के बिना फ़्लोटिंग तिथियां)? यूटीसी टाइमज़ोन के साथ देशी जेएस तिथि का उपयोग करना और दस्तावेज़ों में यूटीसी होने का दावा करना बेहद भ्रमित है क्योंकि यह तब तक काम करता है जब तक कि यह आपको डीएसटी बग से हिट न करे।

मैं एक वस्तु का सुझाव दूंगा, चलिए इसे "RRuleDate" कहते हैं जो (year, month, day, hours?, minutes?, seconds?, milliseconds?) कंस्ट्रक्टर लेता है और इसमें .toDate() विधि है।

यह RRuleDate वह है जो before() , after() , between() , और all() वापस आना चाहिए, और केवल एक चीज जो before() , after() , between() और dtstart विकल्प को पैरामीटर के रूप में स्वीकार करना चाहिए।