# फ़ील्ड फ़ॉर्मेट
फ़ील्ड का नाम अनुमान लगाने वाला मॉडल या तो `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` लौटाते हैं सही फ़ील्ड नाम के साथ:
```json
{ "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` भेजो, और सर्वर टाइमज़ोन डेटाबेस से ऑफ़सेट लेगा, साथ ही डेलाइट सेविंग टाइम के साथ।
```json
{ "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](/api-conventions/#невідомий-час-народження).
## अज्ञात कुंजियाँ अस्वीकार नहीं होतीं
बॉडी चुपचाप अतिरिक्त फ़ील्ड ले लेता है: अज्ञात कुंजी बस अनदेखी कर दी जाती है। इसलिए ऊपर की अस्वीकृति सूची में न होने वाले फ़ील्ड नाम की गलती पता नहीं चलेगी। स्पेसिफिकेशन देखें: [`/v1/openapi.json`](https://api.astroway.info/v1/openapi.json).
## आगे
- [Common Mistakes](/agent-setup/mistakes/)
- [Gotchas](/agent-setup/gotchas/)