Supported timezones
FalakAPI resolves local dates and clocks using the IANA Time Zone Database. You can pass a zone name directly, rely on latitude/longitude to infer a zone, or use curated aliases for crowded abbreviations like IST.
IANA timezone names (primary)
Where an API accepts tz, timezone, from_tz, or to_tz, the preferred value is an IANA ID such as Asia/Kolkata, Asia/Riyadh, or America/Argentina/Buenos_Aires. Any identifier accepted by Go's timezone data in the deployment (typically the full tz DB shipped with tzdata on Linux) is supported.
Authoritative naming and zone boundaries are maintained in the IANA time zone database; community lists such as Wikipedia's "List of tz database time zones" are useful references for picking the right region-specific ID.
Accepted aliases (abbreviations & shortcuts)
Before lookup, FalakAPI normalizes the string (trims whitespace, treats hyphens/spaces like underscores, compares case-insensitively against the mappings below). Anything else is passed through unchanged as an IANA name.
| You can pass | Resolved IANA zone |
|---|---|
| UTC, GMT, UT, Z, Zulu | UTC |
| IST, India, Indian_Standard_Time, India_Standard_Time | Asia/Kolkata |
| PKT, Pakistan, Pakistan_Standard_Time | Asia/Karachi |
| BDT, Bangladesh, Bangladesh_Standard_Time | Asia/Dhaka |
| GST, UAE, Dubai, Emirates | Asia/Dubai |
| AST, AST_SA, Saudi, Riyadh, Arabia_Standard_Time | Asia/Riyadh |
| TRT, Turkey, Istanbul | Europe/Istanbul |
| WET, WEST | Europe/London |
| JST | Asia/Tokyo |
| KST | Asia/Seoul |
| EST_US, US_Eastern, USEastern | America/New_York |
| CST_US, US_Central | America/Chicago |
| MST_US, US_Mountain | America/Denver |
| PST_US, US_Pacific | America/Los_Angeles |
Ambiguous abbreviations elsewhere in the world (for example IST meaning Israel Standard Time in some contexts) are not all mapped—when in doubt, use the explicit Asia/… or Europe/… IANA ID.
Inference from latitude & longitude
Several endpoints optionally omit a timezone parameter and derive the local zone from lat and lng. Resolution order:
- When polygon-based boundary data is available in the running service, coordinates are classified into the correct IANA region first.
- If that data is not present or misses a point, a built-in coarse geographic fallback is used so most on-land coordinates still return a sensible zone rather than failing outright.
For authoritative border cases (narrow slices near zone edges, unusual enclaves), prefer passing an explicit IANA ID from the device or user profile when you already know it.
Where timezone parameters appear
- Prayer times — optional
tz(omit or empty → auto-detect from coordinates). Usetz=UTCexplicitly for UTC-backed local midnight semantics where applicable. - Moon phases — optional
tzwith the same rules. - Hijri calendar — optional
tzaligned with coordinate-based local date. - Time API —
timezone,from_tz,to_tzplus auto-detection from coordinates on supported routes. - Geo timezone — returns the resolved IANA name for a coordinate pair using the same resolution stack.
- Webhooks — subscription payloads may include
timezone; use IANA IDs for stability.