Turns a wall-clock birth time and a pair of coordinates into an unambiguous instant. Every other endpoint here wants either a timezone-aware timestamp or a numeric UTC offset, and getting that wrong is the commonest cause of a chart that is quietly an hour or a day out, so this is usually the first call you make.
Send `date`, `time`, `latitude` and `longitude`. The coordinates are resolved to an IANA time zone, the naive date and time are read in that zone, and you get back `input_datetime`, the resolved `timezone` name, `localized_datetime` with its offset attached, and `utc_datetime`. Feed the localised value straight into `date_time` elsewhere.
One caveat: the request field is spelt `use_LMT` but the view reads a differently-spelt name, so local mean time is never actually applied and the IANA zone is always used — `use_lmt` in the response is always false. For births before standard time was adopted locally, work out the local mean time offset yourself (four minutes per degree of longitude) rather than relying on this flag.
Request fields
Field
Type
Required
Notes
date
string (date)
required
FORMAT constraint, not an enum. DRF DateField with default input formats = ISO-8601 only: 'YYYY-MM-DD'.
latitude
number (double)
required
Latitude of the place, in decimal degrees. Positive is north, negative is south. Example: 26.9124 for Jaipur, 40.7128 for New York. Minutes and seconds are not accepted - convert first.
min -180 · max 180
longitude
number (double)
required
Longitude of the place, in decimal degrees. Positive is east, negative is west. Example: 75.7873 for Jaipur, -74.0060 for New York. Note the sign: a missing minus puts New York in China.
min -180 · max 180
time
string (time)
required
FORMAT constraint, not an enum. DRF TimeField with default input formats = ISO-8601 only: 'HH:MM', 'HH:MM:SS' or 'HH:MM:SS.ffffff'. The catalogue sample value "string" is misleading.