फ़ील्ड फ़ॉर्मेट
फ़ील्ड का नाम अनुमान लगाने वाला मॉडल या तो 400 प्राप्त करता है, या उससे भी बदतर, किसी अन्य चार्ट के बारे में निश्चित उत्तर देता है। नीचे सटीक अनुबंध है।
कार्ड अनुरोध का बॉडी
Section titled “कार्ड अनुरोध का बॉडी”| फ़ील्ड | प्रकार और फ़ॉर्मेट | आवश्यक |
|---|---|---|
date | YYYY-MM-DD, और यह एक वास्तविक कैलेंडर दिन होना चाहिए | हाँ |
time | HH:mm:ss | हाँ, या timeUnknown: true |
timezoneOffset | संख्या, UTC से घंटे, उदाहरण 5.75 | नहीं, डिफ़ॉल्ट 0 (UTC) |
timezone | IANA टाइमज़ोन नाम, उदाहरण Europe/Kyiv, या auto | नहीं, और जब भेजा जाता है, तो timezoneOffset को बदल देता है |
latitude | दशमलव डिग्री, उत्तर धनात्मक | हाँ |
longitude | दशमलव डिग्री, पूर्व धनात्मक | हाँ |
houseSystem | एक अक्षर, डिफ़ॉल्ट P | नहीं |
city | स्ट्रिंग, केवल लेबल | नहीं |
zodiacType | tropical या sidereal | नहीं |
संक्षिप्त लेखन अस्वीकार किए जाते हैं
Section titled “संक्षिप्त लेखन अस्वीकार किए जाते हैं”lat, lon, lng, long, tz, tzOffset, utcOffset, gmtOffset, timeZone, time_zone 400 INVALID_FIELD लौटाते हैं सही फ़ील्ड नाम के साथ:
{ "error": { "code": "INVALID_FIELD", "message": "Unsupported field \"tz\". Rename it to \"timezoneOffset\" (numeric hours from UTC, e.g. 5.75; a zone name goes in timezone)." } }केस और मान के विभाजक नहीं होते: TZ_Offset और tzoffset भी इसी तरह अस्वीकार होते हैं। सभी पाए गए फ़ील्ड एक साथ रिपोर्ट किए जाते हैं, न कि पहला, ताकि एक बार में सभी को सुधारा जा सके।
कड़ी वजह: इस जांच से पहले, वह फ़ील्ड जिसे API नहीं पढ़ता था, चुपचाप ऑफ़सेट 0 देता था, और उत्तर UTC के लिए एक निश्चित चार्ट होता था। तीन घंटे का ऑफ़सेट लगभग 45° असेंडेंट के बराबर है, यानी एक अलग राशि जो उग रही है, और कोई चेतावनी नहीं।
timezone: ऑफ़सेट के बजाय ज़ोन का नाम
Section titled “timezone: ऑफ़सेट के बजाय ज़ोन का नाम”ऑफ़सेट वह होना चाहिए जो घड़ियों ने उसी तारीख पर रखा था, और मैन्युअल रूप से इसे गलत देना आसान है: 1990 के मई में कीव मॉस्को के ग्रीष्मकालीन समय, UTC+4, पर चल रहा था, +3 नहीं। timezone भेजो, और सर्वर टाइमज़ोन डेटाबेस से ऑफ़सेट लेगा, साथ ही डेलाइट सेविंग टाइम के साथ।
{ "date": "1990-05-15", "time": "14:30:00", "timezone": "Europe/Kyiv", "latitude": 50.45, "longitude": 30.52 }autolatitudeऔरlongitudeके आधार पर ज़ोन निर्धारित करता है। सीमा के पास नाम अधिक सटीक होता है।- यदि
timezoneऔरtimezoneOffsetसाथ में आएँ, तोtimezoneलागू होता है। उत्तर मेंinput.timezoneOffsetवह ऑफ़सेट दिखाता है जो उपयोग किया गया था। - वह समय जो दो बार हुआ (जब घड़ियों को पीछे ले जाया गया), पहले बार के अनुसार लिया जाता है। वह समय जो नहीं हुआ (जब आगे ले जाया गया), उस पर लागू ऑफ़सेट वह होता है जो परिवर्तन से पहले था।
timeके बिना (सिर्फ़ तिथि याtimeUnknown: true) ज़ोन स्थानीय दोपहर पर पढ़ा जाता है।400 INVALID_FIELDके साथ अस्वीकार होते हैं: खाली मान,ESTयाPSTजैसी संक्षिप्तियां, टेक्स्ट में लिखा ऑफ़सेट जैसे+03:00, ऐसे नाम जो डेटाबेस में नहीं हैं, और बिना कोऑर्डिनेट्स केauto।UTCऔरGMTस्वीकार किए जाते हैं।- हर ऑब्जेक्ट अलग से प्रोसेस होता है, इसलिए
chart1औरchart2अलग-अलग ज़ोनों में हो सकते हैं।
houseSystem: अक्षर, नाम नहीं
Section titled “houseSystem: अक्षर, नाम नहीं”सटीक ये 25 कोड Swiss Ephemeris से स्वीकार किए जाते हैं:
P K R C E W B M O A T V D F G H I i L N Q S U X Y
केस मायने रखता है: I मैक्रांसकी के अनुसार Sunshine है, i ट्रेंडलेम के अनुसार। सिस्टम का नाम ("Placidus", "Koch") 400 लौटाता है। पहले यह यादृच्छिक रूप से काम करता था, क्योंकि इंजन स्ट्रिंग से केवल पहला अक्षर पढ़ता है, और उसी कारण "Zodiac" चुपचाप Placidus देता था।
अज्ञात जन्म समय
Section titled “अज्ञात जन्म समय”किसी बनावटी दोपहर के बजाय timeUnknown: true भेजो और time न भेजो। तब houses, houseAspects, chartSect और siderealTime null आएँगे, न कि बनावटी मान। विवरण: API Conventions.
अज्ञात कुंजियाँ अस्वीकार नहीं होतीं
Section titled “अज्ञात कुंजियाँ अस्वीकार नहीं होतीं”बॉडी चुपचाप अतिरिक्त फ़ील्ड ले लेता है: अज्ञात कुंजी बस अनदेखी कर दी जाती है। इसलिए ऊपर की अस्वीकृति सूची में न होने वाले फ़ील्ड नाम की गलती पता नहीं चलेगी। स्पेसिफिकेशन देखें: /v1/openapi.json.