फ़ील्ड फ़ॉर्मेट

Last updated 18 सित॰ 2026 Markdown के रूप में देखें एजेंट सेटअप

फ़ील्ड का नाम अनुमान लगाने वाला मॉडल या तो 400 प्राप्त करता है, या उससे भी बदतर, किसी अन्य चार्ट के बारे में निश्चित उत्तर देता है। नीचे सटीक अनुबंध है।

कार्ड अनुरोध का बॉडी

फ़ील्ड	प्रकार और फ़ॉर्मेट	आवश्यक
`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`	नहीं

संक्षिप्त लेखन अस्वीकार किए जाते हैं

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`: ऑफ़सेट के बजाय ज़ोन का नाम

ऑफ़सेट वह होना चाहिए जो घड़ियों ने उसी तारीख पर रखा था, और मैन्युअल रूप से इसे गलत देना आसान है: 1990 के मई में कीव मॉस्को के ग्रीष्मकालीन समय, UTC+4, पर चल रहा था, +3 नहीं। timezone भेजो, और सर्वर टाइमज़ोन डेटाबेस से ऑफ़सेट लेगा, साथ ही डेलाइट सेविंग टाइम के साथ।

{ "date": "1990-05-15", "time": "14:30:00", "timezone": "Europe/Kyiv",
  "latitude": 50.45, "longitude": 30.52 }

auto latitude और longitude के आधार पर ज़ोन निर्धारित करता है। सीमा के पास नाम अधिक सटीक होता है।
यदि timezone और timezoneOffset साथ में आएँ, तो timezone लागू होता है। उत्तर में input.timezoneOffset वह ऑफ़सेट दिखाता है जो उपयोग किया गया था।
वह समय जो दो बार हुआ (जब घड़ियों को पीछे ले जाया गया), पहले बार के अनुसार लिया जाता है। वह समय जो नहीं हुआ (जब आगे ले जाया गया), उस पर लागू ऑफ़सेट वह होता है जो परिवर्तन से पहले था।
time के बिना (सिर्फ़ तिथि या timeUnknown: true) ज़ोन स्थानीय दोपहर पर पढ़ा जाता है।
400 INVALID_FIELD के साथ अस्वीकार होते हैं: खाली मान, EST या PST जैसी संक्षिप्तियां, टेक्स्ट में लिखा ऑफ़सेट जैसे +03:00, ऐसे नाम जो डेटाबेस में नहीं हैं, और बिना कोऑर्डिनेट्स के auto। UTC और GMT स्वीकार किए जाते हैं।
हर ऑब्जेक्ट अलग से प्रोसेस होता है, इसलिए chart1 और chart2 अलग-अलग ज़ोनों में हो सकते हैं।

`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 देता था।

अज्ञात जन्म समय

किसी बनावटी दोपहर के बजाय timeUnknown: true भेजो और time न भेजो। तब houses, houseAspects, chartSect और siderealTime null आएँगे, न कि बनावटी मान। विवरण: API Conventions.

अज्ञात कुंजियाँ अस्वीकार नहीं होतीं

बॉडी चुपचाप अतिरिक्त फ़ील्ड ले लेता है: अज्ञात कुंजी बस अनदेखी कर दी जाती है। इसलिए ऊपर की अस्वीकृति सूची में न होने वाले फ़ील्ड नाम की गलती पता नहीं चलेगी। स्पेसिफिकेशन देखें: /v1/openapi.json.

आगे

संपादन सुझाएं

// पिछला

ध्यान देने योग्य बातें

अगला //

अवलोकन