Package google.type

इंडेक्स

तारीख

कैलेंडर की पूरी या कुछ तारीख दिखाता है, जैसे कि जन्मदिन. दिन का समय और टाइम ज़ोन, कहीं और बताया गया है या यह जानकारी ज़रूरी नहीं है. तारीख, ग्रेगोरियन कैलेंडर के हिसाब से होती है. यह इनमें से किसी एक को दिखा सकता है:

  • पूरी तारीख, जिसमें साल, महीना, और दिन की वैल्यू शून्य से ज़्यादा होनी चाहिए.
  • साल के तौर पर शून्य के साथ महीना और दिन (उदाहरण के लिए, सालगिरह).
  • साल, जिसमें महीना और दिन शून्य है.
  • साल और महीना, जिसमें दिन की वैल्यू शून्य हो. उदाहरण के लिए, क्रेडिट कार्ड के खत्म होने की तारीख.

मिलते-जुलते टाइप:

फ़ील्ड
year

int32

तारीख का साल. यह संख्या 1 से 9999 के बीच होनी चाहिए. अगर साल के बिना तारीख बतानी है, तो 0 डालें.
month

int32

साल का महीना. यह 1 से 12 के बीच की कोई संख्या होनी चाहिए. अगर महीने और दिन के बिना साल की जानकारी देनी है, तो 0 डालें.
day

int32

महीने का दिन. यह वैल्यू 1 से 31 के बीच होनी चाहिए. साथ ही, यह साल और महीने के लिए मान्य होनी चाहिए. इसके अलावा, साल या साल और महीने के लिए 0 भी डाला जा सकता है, जहां दिन की वैल्यू ज़रूरी नहीं है.

DayOfWeek

हफ़्ते का दिन दिखाता है.

Enums
DAY_OF_WEEK_UNSPECIFIED हफ़्ते का दिन तय नहीं किया गया है.
MONDAY सोमवार
TUESDAY मंगलवार
WEDNESDAY बुधवार
THURSDAY गुरुवार
FRIDAY शुक्रवार
SATURDAY शनिवार
SUNDAY रविवार

इंटरवल

यह किसी समयावधि को दिखाता है. इसे टाइमस्टैंप के शुरू होने और खत्म होने के तौर पर एन्कोड किया जाता है.

शुरू होने की तारीख, खत्म होने की तारीख से कम या उसके बराबर होनी चाहिए. अगर शुरू होने का समय और खत्म होने का समय एक ही है, तो इंटरवल खाली होता है (कोई समय मैच नहीं करता). अगर शुरू और खत्म होने का समय नहीं बताया गया है, तो इंटरवल किसी भी समय से मैच होता है.

फ़ील्ड
start_time

Timestamp

ज़रूरी नहीं. इंटरवल शुरू होने का समय शामिल है.

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

Timestamp

ज़रूरी नहीं. इंटरवल खत्म होने का समय (अलग से उपलब्ध).

अगर यह तय किया गया है, तो इस इंटरवल से मैच करने वाला टाइमस्टैंप, खत्म होने से पहले होना चाहिए.

फ़ोन नंबर

फ़ोन नंबर दिखाने वाला ऑब्जेक्ट, जो एपीआई वायर फ़ॉर्मैट के तौर पर काम करता है.

इस जानकारी से:

  • का इस्तेमाल, स्थानीय भाषा के हिसाब से फ़ोन नंबर को फ़ॉर्मैट करने के लिए नहीं किया जाना चाहिए. जैसे, "+1 (650) 253-0000 एक्सटेंशन 123"

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

  • डायल करने के लिए सही नहीं हो सकता - इसके लिए, नंबर को पार्स करने के लिए खास लाइब्रेरी (रेफ़रंस देखें) का इस्तेमाल किया जाना चाहिए

इस नंबर का इस्तेमाल करने के लिए, पहले इसे i18n.phonenumbers.PhoneNumber ऑब्जेक्ट में बदलें. जैसे, अलग-अलग इस्तेमाल के उदाहरणों के लिए इसे फ़ॉर्मैट करना.

उदाहरण के लिए, Java में यह इस तरह दिखेगा:

com.google.type.PhoneNumber wireProto =
    com.google.type.PhoneNumber.newBuilder().build();
com.google.i18n.phonenumbers.Phonenumber.PhoneNumber phoneNumber =
    PhoneNumberUtil.getInstance().parse(wireProto.getE164Number(), "ZZ");
if (!wireProto.getExtension().isEmpty()) {
  phoneNumber.setExtension(wireProto.getExtension());
}

रेफ़रंस: - https://github.com/google/libphonenumber

फ़ील्ड
extension

string

फ़ोन नंबर का एक्सटेंशन. आईटीयू के सुझावों में, एक्सटेंशन को स्टैंडर्ड नहीं बनाया गया है. हालांकि, इसे संख्याओं की एक सीरीज़ के तौर पर परिभाषित किया गया है, जिसमें ज़्यादा से ज़्यादा 40 अंक हो सकते हैं. अंकों के अलावा, डायल करने के लिए इस्तेमाल होने वाले कुछ अन्य वर्ण भी यहां सेव किए जा सकते हैं. जैसे, ',' (इंतज़ार का संकेत) या '#'.

ध्यान दें कि फ़िलहाल कोई भी क्षेत्र, शॉर्ट कोड वाले एक्सटेंशन का इस्तेमाल नहीं करता. इसलिए, आम तौर पर यह फ़ील्ड सिर्फ़ E.164 नंबर के साथ सेट किया जाता है. इसे E.164 नंबर से अलग रखा जाता है, ताकि आने वाले समय में शॉर्ट कोड एक्सटेंशन की अनुमति दी जा सके.
यूनियन फ़ील्ड kind. ज़रूरी है. कोई सामान्य नंबर या शॉर्ट कोड. आने वाले समय में, यहां दिए गए oneof में नए फ़ील्ड जोड़े जा सकते हैं. इसलिए, क्लाइंट को ऐसे फ़ोन नंबरों को अनदेखा करना चाहिए जिनके लिए कोड किए गए फ़ील्ड में से कोई भी फ़ील्ड सेट नहीं है. kind इनमें से कोई एक हो सकता है:
e164_number

string

फ़ोन नंबर, जिसे सबसे पहले प्लस के निशान ('+') के तौर पर दिखाया जाता है. इसके बाद, फ़ोन नंबर आता है, जो ITU E.164 फ़ॉर्मैट का इस्तेमाल करता है. इसमें देश का कॉलिंग कोड (1 से 3 अंक) और सदस्य का नंबर शामिल होता है. इसमें कोई अतिरिक्त स्पेस या फ़ॉर्मैटिंग नहीं होती. उदाहरण के लिए: - सही: "+15552220123" - गलत: "+1 (555) 222-01234 x123".

आईटीयू E.164 फ़ॉर्मैट के मुताबिक, फ़ोन नंबर 12 अंकों का होना चाहिए. हालांकि, सभी देश इस फ़ॉर्मैट का पालन नहीं करते. इसलिए, हम इस पाबंदी को हटा देते हैं. सिर्फ़ देश के अंदर इस्तेमाल होने वाले नंबर इस्तेमाल नहीं किए जा सकते.

रेफ़रंस: - https://www.itu.int/rec/T-REC-E.164-201011-I - https://en.wikipedia.org/wiki/E.164. - https://en.wikipedia.org/wiki/List_of_country_calling_codes
short_code

ShortCode

कोई छोटा कोड.

रेफ़रंस: - https://en.wikipedia.org/wiki/Short_code

ShortCode

यह शॉर्ट कोड दिखाने वाला ऑब्जेक्ट होता है. यह एक ऐसा फ़ोन नंबर होता है जो आम तौर पर सामान्य फ़ोन नंबर से काफ़ी छोटा होता है. इसका इस्तेमाल, एमएमएस और एसएमएस सिस्टम में मैसेज भेजने के लिए किया जा सकता है. साथ ही, इसका इस्तेमाल कम वर्णों में डायल करने के लिए भी किया जा सकता है. उदाहरण के लिए, "अपने प्लान में बचे हुए मिनट देखने के लिए, 611 पर मैसेज भेजें."

छोटे कोड किसी एक इलाके के लिए ही होते हैं. इनका इस्तेमाल अंतरराष्ट्रीय स्तर पर नहीं किया जा सकता. इसका मतलब है कि एक ही छोटे कोड का इस्तेमाल अलग-अलग इलाकों में किया जा सकता है. साथ ही, इनकी कीमत और इस्तेमाल भी अलग-अलग हो सकता है. भले ही, उन इलाकों का देश कोड एक ही हो (उदाहरण के लिए: अमेरिका और कनाडा).

फ़ील्ड
region_code

string

ज़रूरी है. उस जगह का BCP-47 क्षेत्र कोड जहां इस शॉर्ट कोड पर कॉल किए जा सकते हैं, जैसे कि "US" और "BB".

रेफ़रंस: - http://www.unicode.org/reports/tr35/#unicode_region_subtag
number

string

ज़रूरी है. शॉर्ट कोड के अंक, जिनमें सबसे पहले प्लस ('+') या देश का कॉलिंग कोड नहीं है. उदाहरण के लिए, "611".

PostalAddress

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

आम तौर पर, प्रोसेस के टाइप के हिसाब से, उपयोगकर्ता के इनपुट या मौजूदा डेटा को इंपोर्ट करके पता बनाया जाएगा.

पते के इनपुट या उसमें बदलाव करने के बारे में सलाह: - अंतरराष्ट्रीय स्तर पर इस्तेमाल किए जा सकने वाले पते के विजेट का इस्तेमाल करें. जैसे, https://github.com/google/libaddressinput) - उपयोगकर्ताओं को उन देशों के बाहर के फ़ील्ड में इनपुट करने या उनमें बदलाव करने के लिए, यूज़र इंटरफ़ेस (यूआई) एलिमेंट नहीं दिखाए जाने चाहिए जहां उस फ़ील्ड का इस्तेमाल किया जाता है.

इस स्कीमा का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, यह देखें: https://support.google.com/business/answer/6397478

फ़ील्ड
revision

int32

PostalAddress के स्कीमा में किया गया बदलाव. इसे 0 पर सेट करना चाहिए, जो कि सबसे नया बदलाव है.

सभी नए बदलाव, पुराने बदलावों के साथ काम करने चाहिए.
region_code

string

ज़रूरी है. पते के देश/इलाके का CLDR कोड. इसकी जानकारी कभी भी अनुमानित नहीं की जाती. यह उपयोगकर्ता की ज़िम्मेदारी है कि वह पक्का करे कि वैल्यू सही हो. ज़्यादा जानकारी के लिए, https://cldr.unicode.org/ और https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html देखें. उदाहरण: स्विट्ज़रलैंड के लिए "CH".
language_code

string

ज़रूरी नहीं. इस पते के कॉन्टेंट का BCP-47 भाषा कोड (अगर पता हो). आम तौर पर, यह इनपुट फ़ॉर्म के यूज़र इंटरफ़ेस (यूआई) की भाषा होती है. इसके अलावा, यह पता है कि यह भाषा, पते के देश/इलाके में इस्तेमाल की जाने वाली किसी भाषा या ट्रांसलिटरेट की गई किसी भाषा से मेल खाती है. इससे कुछ देशों में फ़ॉर्मैटिंग पर असर पड़ सकता है. हालांकि, यह डेटा की सटीक जानकारी के लिए ज़रूरी नहीं है. साथ ही, इससे पुष्टि करने या फ़ॉर्मैटिंग से जुड़े अन्य कामों पर कभी असर नहीं पड़ेगा.

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

उदाहरण: "zh-Hant", "ja", "ja-Latn", "en".
postal_code

string

ज़रूरी नहीं. पते का पिन कोड. सभी देश, पिन कोड का इस्तेमाल नहीं करते या यह ज़रूरी नहीं होता कि पते में पिन कोड शामिल हो. हालांकि, जिन देशों में पिन कोड का इस्तेमाल किया जाता है वहां पते के अन्य हिस्सों के साथ अतिरिक्त पुष्टि की जा सकती है. उदाहरण के लिए, अमेरिका में राज्य/पिन कोड की पुष्टि.
sorting_code

string

ज़रूरी नहीं. देश के हिसाब से, क्रम से लगाने के लिए अतिरिक्त कोड. ज़्यादातर इलाकों में इसका इस्तेमाल नहीं किया जाता. जहां इसका इस्तेमाल किया जाता है वहां वैल्यू, "CEDEX" जैसी स्ट्रिंग होती है. इसके बाद, वैल्यू के तौर पर कोई संख्या भी हो सकती है. उदाहरण के लिए, "CEDEX 7". इसके अलावा, वैल्यू सिर्फ़ एक संख्या भी हो सकती है. यह संख्या, "सेक्टर कोड" (जमैका), "डिलीवरी एरिया इंडिकेटर" (मलावी) या "पोस्ट ऑफ़िस इंडिकेटर" (उदाहरण के लिए, कोट डी आइवर) को दिखाती है.
administrative_area

string

ज़रूरी नहीं. किसी देश या इलाके के डाक पते के लिए इस्तेमाल होने वाला सबसे बड़ा एडमिन के तौर पर उपखंड. उदाहरण के लिए, यह कोई राज्य, प्रांत, ओब्लास्ट या प्रीफ़ेक्चर हो सकता है. खास तौर पर, स्पेन के लिए यह प्रांत है, न कि ऑटोनोमस कम्यूनिटी (उदाहरण के लिए, "बार्सिलोना", न कि "कैटलोनिया"). कई देश, डाक पते में प्रशासनिक क्षेत्र का इस्तेमाल नहीं करते. उदाहरण के लिए, स्विट्ज़रलैंड में इस फ़ील्ड को खाली छोड़ा जाना चाहिए.
locality

string

ज़रूरी नहीं. आम तौर पर, इसका मतलब पते के शहर/कस्बे से होता है. उदाहरण: अमेरिका का शहर, इटली का कम्यून, यूनाइटेड किंगडम का पोस्ट टाउन. दुनिया के उन इलाकों में जहां इलाकों की जानकारी साफ़ तौर पर नहीं दी गई है या जो इस स्ट्रक्चर में सही से फ़िट नहीं होते, वहां locality को खाली छोड़ें और address_lines का इस्तेमाल करें.
sublocality

string

ज़रूरी नहीं. पते की उप-इलाका. उदाहरण के लिए, यह इलाके, नगर, जिले हो सकते हैं.
address_lines[]

string

पते की निचली लाइनों की जानकारी देने वाली, बिना स्ट्रक्चर वाली लाइनें.

address_lines में मौजूद वैल्यू में टाइप की जानकारी नहीं होती और कभी-कभी एक फ़ील्ड में कई वैल्यू हो सकती हैं. उदाहरण के लिए, "ऑस्टिन, टेक्सास". इसलिए, यह ज़रूरी है कि लाइन का क्रम साफ़ तौर पर दिखे. पते के देश/इलाके के हिसाब से, पते की लाइन का क्रम "एनवलप का क्रम" होना चाहिए. जिन देशों/इलाकों में यह क्रम अलग-अलग हो सकता है (जैसे, जापान), वहां address_language का इस्तेमाल करके यह जानकारी दी जाती है. उदाहरण के लिए, बड़े से छोटे क्रम के लिए "ja" और छोटे से बड़े क्रम के लिए "ja-Latn" या "en". इस तरह, भाषा के आधार पर पते की सबसे खास लाइन चुनी जा सकती है.

किसी पते के स्ट्रक्चर के तौर पर, कम से कम region_code की जानकारी देनी ज़रूरी है. बाकी जानकारी, address_lines में दी जाती है. ऐसे पते को जियोकोडिंग के बिना भी फ़ॉर्मैट किया जा सकता है. हालांकि, पते के किसी भी कॉम्पोनेंट के बारे में तब तक कोई सेमेटिक वजह नहीं बताई जा सकती, जब तक कि उसे कम से कम कुछ हद तक हल नहीं किया जाता.

बिना क्रम के दिए गए पतों को मैनेज करने के लिए, हमारा सुझाव है कि आप सिर्फ़ region_code और address_lines वाला पता बनाएं. इसके बाद, उसे जियोकोड करें. ऐसा करने से, यह अनुमान लगाने की ज़रूरत नहीं पड़ेगी कि पते के किन हिस्सों में इलाके या प्रशासनिक क्षेत्र होने चाहिए.
recipients[]

string

ज़रूरी नहीं. पते पर मौजूद व्यक्ति. कुछ मामलों में, इस फ़ील्ड में एक से ज़्यादा लाइन की जानकारी हो सकती है. उदाहरण के लिए, इसमें "किसके पास है" जानकारी शामिल हो सकती है.
organization

string

ज़रूरी नहीं. पते पर मौजूद संगठन का नाम.

TimeOfDay

दिन का समय दिखाता है. तारीख और टाइम ज़ोन की वैल्यू या तो काम की नहीं है या उसे कहीं और बताया गया है. कोई एपीआई, लीप सेकंड की अनुमति दे सकता है. मिलते-जुलते टाइप google.type.Date और google.protobuf.Timestamp हैं.

फ़ील्ड
hours

int32

24 घंटे के फ़ॉर्मैट में, दिन के घंटे. यह वैल्यू 0 से ज़्यादा या उसके बराबर होनी चाहिए. आम तौर पर, यह वैल्यू 23 से कम या उसके बराबर होनी चाहिए. कारोबार के बंद होने के समय जैसी स्थितियों के लिए, एपीआई "24:00:00" वैल्यू को अनुमति दे सकता है.
minutes

int32

किसी घंटे के मिनट. यह वैल्यू 0 से ज़्यादा या उसके बराबर और 59 से कम या उसके बराबर होनी चाहिए.
seconds

int32

मिनट के सेकंड. यह वैल्यू 0 से ज़्यादा या उसके बराबर होनी चाहिए. आम तौर पर, यह वैल्यू 59 से कम या उसके बराबर होनी चाहिए. अगर एपीआई में लीप-सेकंड की अनुमति है, तो वह 60 की वैल्यू को स्वीकार कर सकता है.
nanos

int32

सेकंड के छोटे से हिस्से, नैनोसेकंड में. यह वैल्यू 0 से ज़्यादा या उसके बराबर और 999,999,999 से कम होनी चाहिए.

TimeZone

IANA टाइम ज़ोन डेटाबेस से किसी टाइम ज़ोन को दिखाता है.

फ़ील्ड
id

string

IANA टाइम ज़ोन डेटाबेस का टाइम ज़ोन. उदाहरण के लिए, "America/New_York".
version

string

ज़रूरी नहीं. IANA टाइम ज़ोन डेटाबेस का वर्शन नंबर. उदाहरण के लिए, "2019a".