टाइम ज़ोन के विकल्प

ऑटोमोटिव सूचना और मनोरंजन की सुविधा देने वाले डिवाइस से, समय को सटीक तरीके से दिखाने की उम्मीद की जाती है. यह इसकी एक मुख्य सुविधा है. यह सुविधा देखने में भले ही आसान लगे, लेकिन जब समय और टाइम ज़ोन को मैनेज करने की उम्मीदें कम हों और उन्हें पूरा करना ज़रूरी हो, तो समय को सटीक तरीके से दिखाना मुश्किल हो जाता है. ऐसा तब होता है, जब बिना किसी मैन्युअल इंटरवेंशन के, सटीक तारीख और समय दिखाना ज़रूरी हो.

आम तौर पर, चिप पर सिस्टम (SoC) में इस्तेमाल होने वाली सभी रीयल-टाइम घड़ियों में कुछ न कुछ गड़बड़ी होती है. यह गड़बड़ी समय के साथ बढ़ती जाती है और अगर इसे ठीक न किया जाए, तो यह बड़ी गड़बड़ी में बदल सकती है. इसके अलावा, स्थानीय समय को सटीक तरीके से दिखाने की उम्मीदें ज़्यादा होती हैं. इसलिए, कोऑर्डिनेटेड यूनिवर्सल टाइम (यूटीसी) से सही ऑफ़सेट को ध्यान में रखना ज़रूरी है.

यह उम्मीद की जा सकती है कि किसी वाहन के अनुमानित लाइफ़टाइम के दौरान, टाइम ज़ोन की जानकारी के साथ-साथ डेलाइट सेविंग टाइम (डीएसटी) लागू करने की जानकारी में भी बदलाव हो सकता है. उदाहरण के लिए, ब्राज़ील ने डीएसटी को कई सालों तक लागू करने के बाद, 2019 में डीएसटी शेड्यूल लागू न करने का फ़ैसला लिया.

Android, टाइम ज़ोन के नियमों को मैनेज करने से जुड़ी मुश्किलों को हल करने के लिए ज़रूरी इन्फ़्रास्ट्रक्चर उपलब्ध कराता है. ज़्यादा जानकारी के लिए, टाइम ज़ोन के नियम देखें. इससे ओईएम, सिस्टम अपडेट की ज़रूरत के बिना, डिवाइसों पर टाइम ज़ोन के अपडेट किए गए नियमों का डेटा पुश कर सकते हैं. इस सुविधा से ये काम किए जा सकते हैं:

  • उपयोगकर्ताओं को समय पर अपडेट मिलते हैं. इससे Android डिवाइस का लाइफ़टाइम बढ़ जाता है.
  • ओईएम, सिस्टम इमेज के अपडेट से अलग, टाइम ज़ोन के अपडेट की जांच कर सकते हैं.

ध्यान दें: AAOS 10, Android 10 (और उसके बाद के वर्शन) की रिलीज़ में उपलब्ध, APEX पर आधारित मॉड्यूल अपडेट करने की सुविधा के साथ काम नहीं करता.

ध्यान दें: इस सुविधा को लागू करने के लिए, सिस्टम को रीबूट करना ज़रूरी है.

कारों में टाइम (ज़ोन) की जानकारी के सोर्स

Android डिवाइस, सिस्टम लेवल पर Unix टाइम में समय को मैनेज करते हैं. इसके बाद, वे मनचाहे टाइम ज़ोन ऑफ़सेट को लागू करते हैं. फिर, उपयोगकर्ताओं को दिखाने के लिए, वैल्यू को स्थानीय समय में बदल देते हैं. मौजूदा उपयोगकर्ता के ज़ोन आईडी (इसे अक्सर ओल्सन आईडी कहा जाता है) को सेटिंग के तौर पर सेव किया जाता है. उदाहरण के लिए, Europe/London.

नीचे बताई गई ज़्यादातर सुविधा में, समय की जानकारी के बारे में बताया गया है. इन स्टैंडर्ड का मकसद, उपयोगकर्ताओं को मौजूदा समय की जानकारी देना है. इनका मकसद, लागू होने वाले टाइम ज़ोन के नियमों के बारे में बताना नहीं है. असल टाइम ज़ोन का पता लगाने के लिए, डिवाइस को ज़ोन आईडी सेट करने से पहले, देश, ऑफ़सेट, और डीएसटी ऑफ़सेट जैसे फ़ैक्टर के आधार पर जानकारी ढूंढनी होती है.

यह प्रोसेस मुश्किल हो सकती है. उपलब्ध जानकारी के आधार पर, जानकारी ढूंढना मुश्किल हो सकता है. उदाहरण के लिए, अमेरिका/डेनवर टाइम ज़ोन के नियम के तहत, डीएसटी लागू होता है. हालांकि, गर्मियों के दौरान यह माउंटेन डेलाइट टाइम (एमडीटी) के हिसाब से काम करता है. वहीं, अमेरिका/फ़ीनिक्स में एमडीटी लागू रहता है.

सेल्युलर रेडियो

सिस्टम की जानकारी (एसआई), लॉन्ग-टर्म इवोल्यूशन (एलटीई) एयर इंटरफ़ेस का एक अहम पहलू है. इसे ब्रॉडकास्ट कंट्रोल चैनल (बीसीएच) पर, बेस स्टेशन (बीएस) से ट्रांसमिट किया जाता है. 3GPP TS 36.331 में, SystemInformationBlockType16 (SIB16) के बारे में बताया गया है. इसमें जीपीएस और कोऑर्डिनेटेड यूनिवर्सल टाइम (यूटीसी), स्थानीय समय ऑफ़सेट, और डीएसटी की जानकारी शामिल होती है.

इसी तरह की सुविधा, 2G और 3G में भी उपलब्ध है. इनमें नेटवर्क आइडेंटिटी और टाइम ज़ोन (एनआईटीज़ेड) की जानकारी ब्रॉडकास्ट की जा सकती है. ज़्यादा जानकारी के लिए, 3GPP TS 22.042 देखें. सेल्युलर रेडियो के अन्य स्टैंडर्ड में भी इसी तरह की सुविधाएं उपलब्ध हैं.

हालांकि, ज़्यादातर स्टैंडर्ड में यह सुविधा उपलब्ध है कि इस जानकारी को भेजना ज़रूरी नहीं है. इसलिए, यह सभी नेटवर्क पर उपलब्ध नहीं होती.

फ़ायदे नुकसान
  • उपलब्ध होने पर, यह ज़्यादातर ज़रूरी जानकारी उपलब्ध कराता है.
  • यह सुविधा इस्तेमाल करने में आसान है. Android में यह सुविधा पहले से उपलब्ध है. हालांकि, यह सुविधा तब काम करती है, जब सेल्युलर रेडियो को सिर्फ़ डेटा मॉडेम के तौर पर नहीं, बल्कि फ़ोन के तौर पर इस्तेमाल किया जाता है.
  • इसके लिए, इंटरनेट कनेक्शन की ज़रूरत नहीं होती.

  • इस बात की कोई गारंटी नहीं है कि जानकारी ब्रॉडकास्ट की जाएगी या बेस स्टेशन सही तरीके से कॉन्फ़िगर किया गया है.

  • सीमावर्ती इलाकों में, आस-पास के देश के (रोमिंग) सेल टावर से कनेक्ट होने और गलत टाइम ज़ोन की जानकारी देने की संभावना होती है.

  • कुछ जगहों पर, अपडेट होने में घंटों या दिनों लग सकते हैं.

नेटवर्क टाइम प्रोटोकॉल

नेटवर्क टाइम प्रोटोकॉल (एनटीपी) का इस्तेमाल अक्सर, Unix epoch टाइम की सटीक जानकारी पाने के लिए किया जाता है. Android, अपने सिस्टम टाइम को एनटीपी सर्वर के टाइम के साथ सिंक करने की सुविधा देता है हालांकि, यह सुविधा तब काम करती है, जब RadioManager के क्लाइंट को, सामान्य RadioTuner.getParameters() मेटाडेटा के ज़रिए यह सुविधा उपलब्ध कराई जाती है. जब एनटीपी का टाइम, सिस्टम टाइम के साथ सिंक नहीं होता है और मोबाइल और इंटरनेट सेवा देने वाली कंपनी ने हाल ही में एनआईटीज़ेड अपडेट नहीं दिया है, तो एनटीपी, सिस्टम टाइम को अपडेट करता है. अगर एनआईटीज़ेड उपलब्ध नहीं है और उपयोगकर्ता AUTO_TIME चालू करता है, तो सिस्टम तुरंत नेटवर्क टाइम की जांच करता है.

फ़ायदे नुकसान

यह सुविधा इस्तेमाल करने में आसान है. Android में यह सुविधा पहले से उपलब्ध है.

  • एनटीपी से सिर्फ़ एक ज़रूरी वैल्यू (टाइम) मिलती है. एनटीपी, टाइम ज़ोन की जानकारी नहीं दे सकता.

  • इसके लिए, इंटरनेट कनेक्शन की ज़रूरत होती है.

ब्रॉडकास्ट रेडियो ट्यूनर

टाइम और टाइम ज़ोन की जानकारी पाने के लिए, बिल्ट-इन ट्यूनर का इस्तेमाल करना अच्छा विकल्प है. हालांकि, इसमें कुछ समस्याएं भी आ सकती हैं. रेडियो ब्रॉडकास्ट के कई स्टैंडर्ड में, ज़रूरी जानकारी उपलब्ध कराने के विकल्प तय किए गए हैं. आम तौर पर, ब्रॉडकास्ट रेडियो ट्यूनर, सेल्युलर रेडियो के जैसी ही जानकारी उपलब्ध कराता है.

ETSI EN 300 401 V1.4.1 (2006-06) के सेक्शन 8.1 में, सेवा की जानकारी से जुड़ी उन सुविधाओं के बारे में बताया गया है जो डिजिटल ऑडियो ब्रॉडकास्टिंग (डीएबी) सिस्टम के लिए, ऑडियो प्रोग्राम और डेटा, दोनों के बारे में अतिरिक्त जानकारी उपलब्ध कराती हैं. सेक्शन 8.1.3 में, टाइम और तारीख के साथ-साथ, देश और स्थानीय समय ऑफ़सेट की जानकारी के लिए फ़ॉर्मैट तय किया गया है.

इसी तरह, FM ट्यूनर में आम तौर पर लागू होने वाले रेडियो डेटा सिस्टम (आरडीएस) के लिए, EN 50067 स्टैंडर्ड के सेक्शन 3.1.5.6 में, घड़ी के टाइम और डेटा (हर मिनट में एक बार ट्रांसमिट किया जाता है) के लिए फ़ॉर्मैट तय किया गया है. इसके अलावा, ट्रांसमिट किए गए प्रोग्राम की पहचान के हिस्से के तौर पर, एक्सटेंडेड कंट्री कोड (ईसीसी) भी पाया जा सकता है.

एचडी रेडियो में, स्टेशन इन्फ़ॉर्मेशन सर्विस (एसआईस) पैरामीटर मैसेज (एमएसजी आईडी 0111) में, स्टेशन इन्फ़ॉर्मेशन सर्विस (एसआईस) पैरामीटर मैसेज (एमएसजी आईडी 0111) में, एचडी रेडियो™ एयर इंटरफ़ेस डिज़ाइन डिस्क्रिप्शन स्टेशन इन्फ़ॉर्मेशन सर्विस ट्रांसपोर्ट स्पेसिफ़िकेशन के हिस्से के तौर पर, इसी तरह के विकल्प शामिल हैं. सेक्शन 5 में, चेतावनी के तौर पर इस्तेमाल किए जाने वाले शब्दों के बारे में साफ़ तौर पर बताया गया है. ब्रॉडकास्ट के घड़ी वाले फ़ीचर का इस्तेमाल करते समय, इन शब्दों को ध्यान में रखना ज़रूरी है. अन्य सिस्टम पर भी यही बात लागू होती है:

... इस डेटा में, ब्रॉडकास्टर की जगह के हिसाब से स्थानीय कस्टम के बारे में बताया जाता है. यह ज़रूरी नहीं है कि यह जानकारी, रिसीवर की जगह के हिसाब से स्थानीय कस्टम के जैसी हो. टाइम-ज़ोन की सीमाओं के आस-पास, उपभोक्ताओं को अलग-अलग डेटा उपलब्ध कराने वाले कई स्टेशन मिल सकते हैं. इसलिए, यह डेटा सिर्फ़ हिंट के तौर पर उपलब्ध कराया जाता है. इसका मतलब और इस्तेमाल, ग्राहक के कंट्रोल के हिसाब से तय किया जाना चाहिए. ..."

इसके अलावा, कम से कम एचडी रेडियो के लिए, इस जानकारी को ब्रॉडकास्ट करना ज़रूरी नहीं है. इसलिए, सिर्फ़ इस पर भरोसा नहीं किया जाना चाहिए.

फ़ायदे नुकसान
  • आम तौर पर, यह सुविधा अलग-अलग रीजनल ब्रॉडकास्ट रेडियो स्टैंडर्ड में उपलब्ध होती है.
  • इसके लिए, इंटरनेट कनेक्शन की ज़रूरत नहीं होती.
  • Android में यह सुविधा पहले से उपलब्ध नहीं है.
  • जानकारी को सटीक तरीके से पाने के लिए, ट्यूनर को चालू रखना ज़रूरी है. इसे बैकग्राउंड में कभी-कभी चालू रखा जा सकता है.

  • जानकारी की सटीक होने की संभावना, ब्रॉडकास्टर पर निर्भर करती है.

सुविधा लागू करने के बारे में सलाह

Android, अपने सिस्टम टाइम को एनटीपी सर्वर के टाइम के साथ सिंक करने की सुविधा देता है. हालांकि, यह सुविधा तब काम करती है, जब RadioManagerके क्लाइंट को यह सुविधा उपलब्ध कराई जाती है. हमारा सुझाव है कि वेंडर एक्सटेंशन की सुविधा का इस्तेमाल करें. इस सुविधा को हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) में लागू किया जाना चाहिए. इसके बाद, RadioManager के क्लाइंट को, सामान्य RadioTuner.getParameters() तरीके के ज़रिए यह सुविधा उपलब्ध कराई जा सकती है.

यह पक्का करने के लिए कि यह सुविधा सही तरीके से काम करे, वेंडर एक्सटेंशन का इस्तेमाल करने वाले को यह तय करना होगा कि एचएएल, इस सुविधा के साथ काम करता है या नहीं. यह मानकर न चलें कि यह सुविधा उपलब्ध है. getParameters कॉल के लिए पैरामीटर स्ट्रिंग को साफ़ तौर पर व्यवस्थित किया जाना चाहिए, ताकि अलग-अलग वेंडर के लिए इसका इस्तेमाल आसानी से किया जा सके. उदाहरण के लिए, अपने संगठन के नेमस्पेस का इस्तेमाल करें. इसके लिए, इसे सही डोमेन के साथ प्रीफ़िक्स करें. जैसे, com.me.timezoneTuner.currenttimezone.

जानकारी के इवेंट-ड्रिवन होने की वजह से, इस जानकारी को पाने के लिए, RadioTuner.Callback.onParametersUpdated() कॉलबैक का इस्तेमाल करना फ़ायदेमंद हो सकता है. अगर इस सुविधा को कॉन्फ़िगर किया जा सकता है, तो setParameters के ऊपर, कस्टम रूटीन का सेट डिज़ाइन करें. उदाहरण के लिए:

com.me.timezoneTuner.currenttimezoneEvent.enable

ग्लोबल नेविगेशन सैटेलाइट सिस्टम (जीएनएसएस) सिर्फ़ सटीक टाइम की जानकारी और पोज़िशन की जानकारी दे सकता है.

भौगोलिक-स्थान

इस समस्या को हल करने के लिए, रिवर्स-जियोकोडिंग की प्रोसेस पूरी करें. साथ ही, पोज़िशन के आधार पर लुकअप करके, देश और टाइम ज़ोन की जानकारी पाएं. किसी वाहन में, जीएनएसएस, जगह की जानकारी पाने का सबसे अच्छा विकल्प है. Google का Time Zone API ज़रूरी कन्वर्ज़न को पूरा करने के लिए ज़रूरी सभी सुविधाएं उपलब्ध कराता है. इसके लिए, इंटरनेट कनेक्शन की ज़रूरत होती है. ऑनलाइन समाधान लागू करते समय, उपयोगकर्ता की निजता को सुरक्षित रखना सबसे ज़रूरी है! उपयोगकर्ता की अनुमति लेना ज़रूरी है, ताकि यह तय किया जा सके कि वह डेटा खर्च की लागत स्वीकार करता है या नहीं. इसके लिए, अनुमति का अनुरोध करना ज़रूरी है.

ऑफ़लाइन इस्तेमाल के लिए, सही समाधान तैयार किया जा सकता है. देश और टाइम ज़ोन की सटीक जानकारी पाने के लिए, सही रिज़ॉल्यूशन वाला स्थानीय मैप डेटाबेस, वाहन के स्टोरेज में फ़िट हो सकता है. इसके साथ ही, टाइम ज़ोन (और देश) की जानकारी को ज़रूरत के हिसाब से अपडेट करने की रणनीति को पूरी तरह से लागू किया जा सकता है. इसके बाद, लोकेशन सबसिस्टम से मिले जीएनएसएस पोज़िशन के आधार पर, देश/टाइम ज़ोन को रिवर्स-जियोकोड किया जा सकता है.

फ़ायदे नुकसान
  • यह सही टाइम ज़ोन की जानकारी सटीक तरीके से दे सकता है.
  • स्थानीय डीबी के मामले में, इसके लिए इंटरनेट कनेक्शन की ज़रूरत नहीं होती.
  • यह ज़्यादातर ड्राइविंग के मामलों में सही तरीके से काम करता है.
  • Android में यह सुविधा पहले से उपलब्ध नहीं है.
  • अगर वाहन, किसी ऐसी जगह पर है जहां जीएनएसएस सैटेलाइट का रिसेप्शन अच्छा नहीं है, तो शुरुआती कॉन्फ़िगरेशन के दौरान, सटीक टाइम, जगह, और टाइम ज़ोन की जानकारी नहीं मिल सकती.
  • स्थानीय डेटाबेस को अपडेट करने की सुविधा की ज़रूरत होती है.
  • इसे लागू करना मुश्किल है.

ब्लूटूथ, वाई-फ़ाई या यूएसबी से कनेक्ट किया गया फ़ोन

टाइम और टाइम ज़ोन का डेटा पाने के लिए, उपयोगकर्ता के फ़ोन का इस्तेमाल करने के लिए कई टेक्नोलॉजी का इस्तेमाल किया जा सकता है. सभी फ़ोन के लिए, कस्टम ऐप्लिकेशन और कंपैनियन ऐप्लिकेशन का एक पेयर, फ़ोन और इन-व्हीकल इंफ़ोटेनमेंट (आईवीआई) सिस्टम, दोनों पर इंस्टॉल होना चाहिए. इसके बाद, तय किए गए इंटरवल पर टाइम को सिंक किया जा सकता है. उदाहरण के लिए, कनेक्शन बनाने पर और जब फ़ोन को नए टाइम ज़ोन में होने का पता चलता है.

ब्लूटूथ लो एनर्जी (बीएलई) के साथ काम करने वाले कुछ फ़ोन, जीएटीटी करंट टाइम कैरक्टरिस्टिक और करंट टाइम सर्विस प्रोफ़ाइल स्पेसिफ़िकेशन 1.1 के ज़रिए टाइम पाने का विकल्प देते हैं. हालांकि, सिर्फ़ इस विकल्प पर भरोसा नहीं किया जा सकता, क्योंकि यह मार्केट के बड़े सेगमेंट के लिए काम नहीं करता.

फ़ायदे नुकसान
  • इसके लिए, इंटरनेट कनेक्शन की ज़रूरत नहीं होती.
  • फ़ोन से पता चले टाइम ज़ोन में बदलाव की जानकारी, मुख्य यूनिट को दी जा सकती है.
  • Android में यह सुविधा पहले से उपलब्ध नहीं है.
  • यह सुविधा सिर्फ़ तब काम करती है, जब फ़ोन, मुख्य यूनिट से कनेक्ट हो.
  • टाइम की जानकारी, फ़ोन से मिलने वाली जानकारी के हिसाब से सही या गलत हो सकती है.
  • इसे लागू करना मुश्किल है.
  • सभी फ़ोन, बीएलई जीएटीटी करंट टाइम सर्विस प्रोफ़ाइल के साथ काम नहीं करते.

सोर्स का इस्तेमाल करना

हर डिवाइस वेंडर को यह तय करना होगा कि उसे किस लेवल की सुविधा देनी है और किन उपयोगकर्ता के सफ़र को सबसे अहम मानना है. जब तक अहम उपयोगकर्ता अनुभवों के बारे में साफ़ तौर पर नहीं समझा जाता, तब तक सबसे अच्छा फ़ैसला नहीं लिया जा सकता. ज़्यादातर मामलों में, वेंडर को सुविधा और इसे लागू करने में लगने वाली मुश्किलों के बीच समझौता करना होता है.

ऊपर बताए गए हर विकल्प के अपने फ़ायदे और नुकसान हैं. उदाहरण के लिए, डिज़ाइन से जुड़ा एक अहम फ़ैसला लेना होगा. इसमें यह तय करना होगा कि कभी-कभी गलत टाइम दिखने की तुलना में, कितनी बार सही टाइम दिखना ज़रूरी है. साथ ही, इसके नुकसान को कैसे मैनेज करना है. एक पूरी तरह से ऑटोमैटिक समाधान, जिसके सभी मामलों में सही तरीके से काम करने की उम्मीद की जा सकती है. हालांकि, यह जानकारी के कई सोर्स के कॉम्बिनेशन पर आधारित होना चाहिए. कोई भी विकल्प, 100% उपलब्धता की गारंटी नहीं दे सकता.

मैन्युअल कॉन्फ़िगरेशन का विकल्प, अस्थायी फ़ॉलबैक के तौर पर आसानी से लागू किया जा सकता है. साथ ही, यह कई उपयोगकर्ताओं के लिए काफ़ी हो सकता है.