Rrule: यूटीसी-लेकिन-नहीं-यूटीसी भ्रम

मैं भी बहुत भ्रमित हूँ।

ठीक है, मुझे मिल गया, रीडमी में यह महत्वपूर्ण पैराग्राफ था:

आपको स्थानीय समय क्षेत्र के लिए इन दो सहायक कार्यों का उपयोग करना होगा। यदि आप 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`);

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

धन्यवाद @davidgoli आपका काम बहुत ही सराहनीय है !!!

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

ऐसा इसलिए होगा क्योंकि लौटाई गई तारीख जिसे आप कंसोल पर प्रिंट कर रहे हैं वह एक जावास्क्रिप्ट तिथि है जिसे एक स्ट्रिंग में परिवर्तित किया जा रहा है, और जावास्क्रिप्ट स्वचालित रूप से यूटीसी में कंसोल के लिए तिथियों को प्रिंट करता है (अपने टाइमस्टैम्प के अंत में 'जेड' देखें जो दर्शाता है शून्य ऑफसेट)। चूंकि आपके चार मामलों में से प्रत्येक में अगली घटनाएं एक ही समय पर हो रही हैं (हालांकि अलग-अलग समय क्षेत्रों में), यह ठीक उसी टाइमस्टैम्प को चार बार प्रिंट कर रहा है।

यह भी ध्यान दें कि जावास्क्रिप्ट Date ऑब्जेक्ट 00:00:00 UTC, गुरुवार, 1 जनवरी 1970 (वहां "UTC" पर ध्यान दें!), मिलीसेकंड की संख्या का उपयोग करके समय का ट्रैक रखता है, कुछ द्वारा नहीं "12:34:56 अपराह्न" या किसी भी प्रकार की स्ट्रिंग व्याख्या की तरह।

@davidgoli

मैं वर्तमान में एक पूर्ण पुनर्लेखन पर काम कर रहा हूं, लेकिन इसे ठीक करने में कुछ समय लगेगा।

आप rSchedule के स्रोत को देखना DateTime ऑब्जेक्ट (लक्सन से नहीं) के साथ किया जाता है जो एक इनपुट लेता है और इसे एक फ्लोटिंग यूटीसी तिथि में परिवर्तित करता है जो इनपुट के बराबर दिखता है । इस यूटीसी डेटाटाइम के साथ इटरेशन किया जाता है इसलिए डीएसटी कोई मुद्दा नहीं है। एक घटना मिलने के बाद, उपयोगकर्ता को इसे देने से पहले इसे उचित समय क्षेत्र में सामान्य तिथि में वापस परिवर्तित कर दिया जाता है।

उदाहरण के लिए: यह तिथि

import { DateTime as LuxonDateTime } from 'luxon';

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

इस यूटीसी तिथि में परिवर्तित किया जाएगा और समय क्षेत्र सहेजा जाएगा

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

ध्यान दें कि यह यूटीसी तिथि लक्सन तिथि के समान दिखती है (वे दोनों 2019/1/1 तरह दिखती हैं) लेकिन, चूंकि वे अलग-अलग समय क्षेत्रों में हैं, वे वास्तव में एक ही समय का प्रतिनिधित्व नहीं करते हैं।

यह कहा जा रहा है, इस विशेष "यूटीसी" तिथि के साथ पुनरावृति करने से हम दिन के उजाले की बचत के समय की चिंता किए बिना पुनरावृति कर सकते हैं। सही तिथि मिलने के बाद, हम वापस लक्सन तिथि में परिवर्तित कर सकते हैं।

उदाहरण के लिए:

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

यह यूटीसी के अनुकूल पुनरावृत्ति तर्क को अच्छा रखता है जबकि अभी भी मनमाना समयक्षेत्र का समर्थन करता है।

@thefliik मुझे आदिम नीचे मिल गए; यह ऐसे सप्ताह हैं जो यहाँ असली सिरदर्द हैं। हालाँकि मैं देख रहा हूँ कि rschedule ने भी (अब तक) byweekno और bysetpos समर्थन पर पंट किया है ...

अरे हां। byweekno बहुत कष्टप्रद है।

कोई खबर?

मुझे लगता है कि Date ऑब्जेक्ट के साथ मुद्दों को सुलझाना आसान है और RRULE लिए घटनाओं की गणना करने में समस्याएं, इसलिए मैं दोनों के संयोजन से पहले उनके बारे में अलग से बात करने जा रहा हूं। मुझे इसे ज्यादातर लिखना पड़ा ताकि मैं समस्या की अपनी समझ को सुलझा सकूं और मुझे लगा कि अगर यह दूसरों की मदद करता है तो मैं यहां पोस्ट करूंगा।

जावास्क्रिप्ट दिनांक वस्तु

मैं इस बात से सहमत नहीं हूं कि JS Date वस्तु अनियमित है, लेकिन वस्तु के साथ सामान्य गलतफहमियां हैं जो ऐसा प्रतीत करती हैं। यह कम से कम कहने में भ्रमित करने वाला है।

जैसा कि @ hlee5zebra ने उल्लेख किया है, Date कन्स्ट्रक्टर के साथ बनाई गई तिथियां हमेशा यूटीसी में दर्शायी जाती हैं। उन्हें स्थानीय समय में प्रदर्शित किया जा सकता है, लेकिन पर्दे के पीछे वे वास्तव में यूनिक्स युग में प्रतिनिधित्व करते हैं। हम तत्काल Date ऑब्जेक्ट पर .getTime() या .toISOString() चला सकते हैं ताकि हम खुद को याद दिला सकें कि हम यूटीसी में काम कर रहे हैं।

कार्यान्वयन भी यूटीसी में सभी प्रसंस्करण करने और उपयोगकर्ता को प्रदर्शन पर केवल स्थानीय समय में परिवर्तित करने के सम्मेलन का सही ढंग से पालन करता है। ऐसा ही होता है कि हम, डेवलपर, उपयोगकर्ता हैं; लेकिन फिर हमारे मन में हमारा अपना उपयोगकर्ता होता है जो पानी को गंदा कर देता है। हमारे ऐप्स विकसित करते समय, हमें सम्मेलन का पालन करना और हमारे बैकएंड में यूटीसी के रूप में तिथियों को सहेजना सुनिश्चित करना चाहिए (जेएस पहले से ही यूटीसी में तारीखों को संसाधित करता है इसलिए हम वहां अच्छे हैं)। यदि आप अपने डेटा स्टोर में तारीखों को यूटीसी के रूप में संग्रहीत करते हैं, तो उन्हें क्लाइंट के पास आईएसओ स्ट्रिंग्स के रूप में पहुंचना चाहिए, Date ऑब्जेक्ट द्वारा सही ढंग से पार्स किया जाना चाहिए, और उपयोगकर्ता के स्थानीय समय में प्रदर्शित किया जाना चाहिए, बिना कोई भारी भार उठाए।

इस लेखन ने मुझे Date वस्तु को समझने और यह पता लगाने में मदद की है कि मैं इसके साथ कितना कुछ कर सकता हूं: https://www.toptal.com/software/definitive-guide-to-datetime-manipulation

रूल

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

उदाहरण के लिए, यदि हमारा उपयोगकर्ता प्रत्येक मंगलवार को होने वाली पुनरावृत्ति चाहता है, तो वे उम्मीद करेंगे कि सभी घटनाएं उनके स्थानीय समय में मंगलवार को होंगी। हालांकि, सभी गणना यूटीसी में की जाती हैं, इसलिए RRULE जैसे:

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

यूटीसी में मंगलवार को घटनाएँ लौटाएगा, लेकिन प्राइम मेरिडियन के काफी पश्चिम में स्थित किसी भी उपयोगकर्ता के लिए, स्थानीय समय में सोमवार को घटनाएँ दिखाई देंगी, जो स्पष्ट रूप से वह परिणाम नहीं है जिसकी किसी को उम्मीद है।

सही तरीके से समझना

जो कुछ भी कहा गया है, इसके लिए डेवलपर को हल करने के लिए क्या करना चाहिए, जावास्क्रिप्ट को यह सोचने के लिए मजबूर करना है कि स्थानीय तिथि वास्तव में एक यूटीसी तिथि है, उस "नकली" तिथि को rrule.js , और पुस्तकालय में इसकी गणना करें यह स्थानीय यूटीसी समय। जब आप .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

जहां तक ​​​​मैं देख सकता हूं, क्रोम, फ़ायरफ़ॉक्स और सफारी सभी तारीखों को स्थानीय समय में स्ट्रिंग के रूप में प्रदर्शित करते हैं जब कंसोल पर लॉग इन करते हैं, और Node.js UTC में ISO स्ट्रिंग्स के रूप में।

@ टिम-फिलिप्स मैं भी अभी इसके लिए पीड़ित हूं और इसके आसपास पाने के लिए किसी प्रकार का बंदर पैच ढूंढ रहा हूं।

मेरे पास 8 बजे ईएसटी पर एक पुनरावर्ती घटना है जो ठीक काम करती है, लेकिन 9 बजे ईएसटी इसे होने से पहले दिन में वापस धकेल रही है।

यह देखने के लिए उत्सुक हैं कि क्या आपको इसका उत्तर मिल सकता है।

@ टिम-फिलिप्स जो एक उत्कृष्ट ब्रेकडाउन है। मैं अभी भी इसके माध्यम से जा रहा हूं, लेकिन ऐसा लगता है कि यह मुझे अंत में समझने में मदद करेगा, धन्यवाद!

@ टिम-फिलिप्स आपके विश्लेषण के लिए धन्यवाद।

हालाँकि, क्या आप निम्नलिखित की व्याख्या कर सकते हैं? ऐसा लगता है कि आपका समाधान अभी भी आपके कंप्यूटर के स्थानीय समय क्षेत्र के आधार पर बुधवार को वापस आ सकता है।

@tonylau अपने कंसोल में टाइमज़ोन में परिवर्तित हो जाएगा। आपको दिनांक के कुछ हिस्सों को प्राप्त करने के लिए getUTC*() विधियों का उपयोग करना चाहिए, जो आपके स्थानीय समय क्षेत्र की परवाह किए बिना समान होंगे।

@davidgoli

मैंने अपना टाइमज़ोन यूटीसी+14 (किरीटिमाटी आइलैंड/लाइन आइलैंड्स टाइम) पर सेट किया है और जब मैं getUTCDay() का उपयोग कर रहा हूं, तब भी मुझे निम्नलिखित मिला। वह दिन अभी भी बुधवार के रूप में लौटाया जाता है जब उसे मंगलवार होना चाहिए?

सैंडबॉक्स: https://codesandbox.io/s/rrule-localutc-conversion-in-short-0uzt1

इस चर्चा के लिए संभावित रूप से प्रासंगिक: https://github.com/tc39/proposal-temporal

@ टिम-फिलिप्स धन्यवाद!!!!!!!!!! वह बहुत मददगार था!!!!!!! क्या आप जानते हैं कि नियम के साथ आईसीएस कैसे बनाया जाता है? जब मैं नोड में आईसीएस पैकेज का उपयोग करता हूं और जब मुझे कैलेंडर आमंत्रण प्राप्त होता है, तो वे एक दिन की छुट्टी पर होते हैं। (लेकिन मैं आपके कोड के कारण अपने डीबी में सब कुछ सही ढंग से डालने में सक्षम हूं !! बहुत-बहुत धन्यवाद।)