ForHosting KIT · Developer Utilities

Maya Long Count from date

This Maya Long Count converter turns one explicit Gregorian date into the five familiar Long Count positions: baktun, katun, tun, uinal, and kin.

● BetaFree · in your browser

Run — free How it works & API

Use it from WebAPIEmailTelegramApp soon

It uses the widely adopted Goodman-Martinez-Thompson correlation constant of 584,283 and treats the input strictly as a UTC calendar day, so results do not move with a device timezone or daylight-saving rule. The response also includes the combined dotted notation, the Julian day number, and the elapsed day count used in the calculation, making the conversion easy to inspect, cite, test, or integrate.

Enter a precise Gregorian calendar day

Provide the date in strict YYYY-MM-DD form, including leading zeroes for a one-digit month or day. For example, December 21, 2012 is entered as 2012-12-21. The converter accepts years from 0001 through 9999 and applies the proleptic Gregorian calendar throughout that range. This means the familiar Gregorian leap-year rules are extended backward even for historical periods before different countries formally adopted that calendar. The input is a calendar date, not a timestamp: there is no hour, offset, location, daylight-saving transition, or implicit current day. That distinction makes repeated calls stable in every environment. Impossible dates such as 2023-02-29, malformed values, timestamps, and missing dates are rejected instead of being silently normalized. If you are starting from a historical source that uses the Julian calendar, convert that source date to its corresponding Gregorian day first. This explicit input contract prevents a calendar-label mismatch from looking like an error in the Maya calculation.

Understand the correlation and calculation

A Long Count conversion requires a correlation between Maya chronology and the Julian day-number system used by modern calendar calculations. This tool states its choice openly: the Goodman-Martinez-Thompson, or GMT, constant 584,283. It first converts the supplied proleptic Gregorian day into an integer Julian day number using integer arithmetic. It then subtracts 584,283 to obtain the number of elapsed kin since the correlated Long Count epoch. That total is decomposed from largest to smallest units. One baktun is 144,000 days, one katun is 7,200 days, one tun is 360 days, one uinal is 20 days, and one kin is one day. The baktun value is not artificially wrapped after thirteen, so dates beyond 13.0.0.0.0 remain ordered and unambiguous. Different scholarly correlation proposals can place the same Gregorian day at a different Long Count. The returned correlation label and Julian day number therefore matter: they tell a reader exactly which convention produced the result and provide intermediate values for independent verification.

Read and use the returned fields

The main result is the dotted long_count string, ordered as baktun.katun.tun.uinal.kin. The same five positions are also returned as separate integer fields, which is more convenient for sorting, display templates, database columns, or further calculations. The total_days field is the complete number of kin elapsed from the chosen correlated epoch, while julian_day_number records the Gregorian date's intermediate day number. The date field repeats the validated input exactly, and correlation identifies the GMT constant used. Because the implementation performs bounded integer operations and never calls a clock, platform date parser, random generator, or remote service, identical input always produces identical JSON. This makes it suitable for educational timelines, museum catalog data, reproducible research notes, test fixtures, and API pipelines. The browser version is useful for individual lookups, while automated requests cost $0.002 each. Preserve the correlation label whenever you publish or exchange a result, especially when comparing it with a source that may use another correlation convention.

What you can do with it

Annotate a historical timeline

Add a consistently correlated Maya Long Count alongside Gregorian dates in an exhibit, article, or classroom chronology.

Validate catalog records

Recompute dotted Long Count values from stored Gregorian dates and retain the correlation and Julian day number for auditability.

Build reproducible date fixtures

Generate deterministic calendar-conversion examples for software tests without relying on host timezone settings or date parsing.

FAQ

Which Maya correlation does this converter use?

It uses the Goodman-Martinez-Thompson correlation constant 584,283 and identifies that convention in every result.

What does each position mean?

From left to right they are baktun, katun, tun, uinal, and kin: units of 144,000, 7,200, 360, 20, and 1 day respectively.

Does my timezone change the answer?

No. The input is interpreted as an explicit UTC calendar day and the calculation does not read a clock or local timezone.

Why might another converter show a different value?

It may use another correlation constant, interpret the source as a Julian rather than Gregorian calendar date, or parse a timestamp in a local timezone.

What does an API conversion cost?

Each API request costs $0.002. The browser converter can be used for individual conversions without an API call.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/date/maya-long-count

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/date/maya-long-count \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"2012-12-21"}'

const res = await fetch("https://api.kit.forhosting.com/date/maya-long-count", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "date": "2012-12-21"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/date/maya-long-count",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "date": "2012-12-21"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/maya-long-count", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"date":"2012-12-21"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"date":"2012-12-21"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/maya-long-count", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "date": "2012-12-21"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "date.maya_long_count",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Read the full KIT documentation →