The Long Count

This page describes the Mayan Long Count (LC) and methods of conversion
from and to Julian Period Days
as well as methods of determining
Calendar Round dates from
LC dates.

Introduction

The Mayan Long Count is a simple count of days since an
arbitrary initiation date. This starting date is, usually, referenced
to Wednesday, 13 August -3113 (or 3114 BC) in what
is known as the Gregorian Proleptic Calendar, i.e.,
our normal Gregorian Calendar cast backwards into time before it
was invented or used.
Any Long Count date may be directly converted into a single number
representing the days passed since (or until) the zero date;
this starting date is shown on Mayan stelae in one of two ways, either
as 0.0.0.0.0 or as the equivalent 13.0.0.0.0. The latter notation
is common but not as widespread as the 0.0.0.0.0Initial Series
date. The 13.0.0.0.0 date counts from a different
starting point, 4 ’Ahaw 8 Sots,
instead of 4 ’Ahaw 8 Kumk’u, but the two forms are mathematically identical.
Once the count of days since or until the starting day is known, the count may be
converted directly into an equivalent
Julian Period Date, by adding a
Correlation Constant (CC,
By far the most common Correlation Constant used by
Mayanists is 584285, first proposed
by Goodman, Martinez and Thompson (thus the name GMT Correlation),
and later designated as the most likely constant by Floyd Lounsbury; refer
to the
Correlation Constant page
for more information and references.

Converting Long Count Dates from/to Julian Period Dates

The Mayan Long Count is probably unique in dating systems around the world.
Many calendars have designated starting points, or “zero” days, but I know
of no other calendar that incorporates into its basic mechanisms a straight count
of days, which is all the Long Count is.
In this it is much like the
Julian Period Date, but Scaliger’s count
of days has not only a specific beginning but also a specific end. It is also
not a fundamental part of the Gregorian calendar, or even of the Julian calendar;
it is restricted in its use to astronomers, calendar freaks and Mayanists.

Summing Long Counts to a Total Number of Days

Since both the Long Count and the Julian Period are rigid day-counting mechanisms,
it is no more difficult to correlate the two than to line up two divisions on a slide rule
(for those of you who remember how slide rules work, or even that there are such things);
conversely, it is as difficult as lining up two divisions on a slide rule. .
You must know which two marks you’re lining up. This, of course, is the crux
of the Mayan Calendar Correlation problem.
Once you’ve decided on a Correlation Constant, however, you know where the two scales
line up and you can just read off the answers.

The first step in the conversion process is to convert your Long Count date into
a single number representing the sum total of the days since, or until, the specified
zero point; Long Counts, in English notation, are represented in the familiar
“n0.n1.n2.n3.n4”
notation, examples of which were given above, i.e., 9.8.9.0.0.
Notation somewhat more familiar to computer geeks is the “LC[0], LC[1],
LC[2], LC[3], LC[4]” style, simply indicating elements of an array used to
represent individual components; here, n4, LC[4],
and Bak’tun stand for exactly the same thing—an index into an array, specifically
indicating the fifth element of five.
The only real gotcha here is that all elements of the array save the second are in radix 20
(or base 20) while n1 (LC[1], or Winal) is radix 18.

If the Mayan calendar were radix 10 as are our own numbers, Mayanists’ computing lives would
be easier; then, a LC date such as 9.8.9.0.0 would simply stand for 98,900
days since zero, and I wouldn’t be writing this. On the other hand, if Mayan calendar dates were
solidly radix 20, as is the Mayan method of summing more ordinary items, such as cacao
beans, then life would again be simpler. Then, 9.8.9.0.0 would stand for 0 times 1
day, 0 times 20 days, 9 times 400 days, 8 times 8000 days
and 9 times 160000 days, giving us a total of 1507600 days.

The Mayans, however, were never ones to simplify things just to make life for future epigraphers easy.

Refer to Mayan Periods and Period Glyphs for a
detailed listing of the number of days in each place of Mayan calendar notation, along with known glyphs
for the places. A (very) condensed version of the table is shown here, however, which is useful
in the conversion of ordinary, 5-place, Long Counts:

Period

Place

Number of Days

Tunn

K’in

0

1

-

Winal

1

20

-

Tun

2

360

1

K’atun

3

7200

2

Bak’tun

4

144000

3

As we saw in the section before the table, converting from a LC date to a single number is not
difficult; you just add the days. Here’s a generalized algorithm (written in
Python)
to count up the number of days for any LC number of n places:

i=0 # Simple counter; tells which place we're on
b=20 # The radix of the current position
totaldays=0 # Total number of days
sumn=1 # This is the number of days '1' in the current position multiplies by.
# Place 0 = 1, place 1 = 18, place 2 = 360, and so on.
lst=[9,8,9,0,0] # A Mayan date
lst.reverse() # Store the list backwards, starting at 0, or K'in
for n in lst:
totaldays=totaldays+(sumn*n)
if i==1:
b=18
else:
b=20
sumn=sumn*b
i=i+1
print totaldays

When we run the program, the output is:

1356840

Be aware that this routine runs into trouble if totaldays gets too large.
There are ways around this problem in Python,
but I will leave the finding
of them as an exercise for the reader (I’ve always wanted to say that!).

Converting a Total Number of Days into a Long Count

Naturally, we need to be able to perform the reverse operation, going from
a count of days to a Long Count set of coeffecients. In our previous
example, we found that 9.8.9.0.0 worked out to 1356840
days. Now, we need to determine the LC date for 1356840, and this,
too, is not very hard. We’re basically making change;i.e.,
doing the equivalent of figuring out how many “pennies,” “nickels,”
“dimes,” and so on are contained in our “dollar amount.”

To start with, we need to find out what value to insert in place 0, or
the K’in position. The simplest way to do that is to just take our
total modulo20; to find the value of ni, we need
to use the radix for ni + 1. For our example total,

k’in = 1356840 % 20
k’in = 0

Next, we have to reduce our total by whatever our remainder was above; for this
particular case, since we had no remainder, we don’t have to do this,
but we need to build it into our algorithm. It is most direct to simply

total = total / 20

as this gets rid of any remainder and reduces the total by the place
value required:

total = 1356840 / 20total = 67842

On the next iteration, we need to remember that the radix for the winal
place is 18, not 20:

winal = 67842 % 18
winal = 0
total = total / 18
total = 3769

After this, we change the radix back to 20 and we can continue
for as many places as there are.
Here’s a general algorithm, again written in Python;
this algorithm, too, suffers when the input number is too large. The Python documentation
contains pointers for workarounds.

Another caution to be aware of in both this algorithm and the previous
one is that neither one will do the right thing in cases where any of
the input values are negative.

Converting the Total Number of Days into a Julian Period Date

Given a Correlation Constant, this step is extremely simple.
Merely add your constant to your total number of days. For our example, using a
constant of 584285, this is:

jpd = CC + totaldays
jpd = 584285 + 1356840
jpd = 1941125

Remember that our jpd here is really 1941125.0, or noon
on the day concerned. If you decide to allow for times of day in your calculations,
you must remember that times of day before noon will produce a jpd one less
than that at noon, which may throw off your calculations when going from jpd
to Long Count. Once we have the jpd, though, we can convert to the Julian
or Gregorian calendars, as desired. Using the usual methods, our example Long
Count date, 9.8.9.0.0 converts to 1941125, which becomes jpd
1941125, which gives us a Gregorian date of Friday, July 9, 602 CE.

Determining the Calendar Round from Long Count Coeffecients

To determine the Calendar Round date for any set of Long Count coeffecients, i.e.,
0.0.0.0.1, you need only apply, in succession, a few simple formulae.
These are shown in (Lounsbury, N.D.; TYPE III Problems), and he notes that
such problems are a special case of TYPE I Problems, or determining the new
Calendar Round day attained by adding a distance number to a Calendar Round
day.
To successfully calculate the Calendar Round from a Long Count date, you need
the starting coordinates in the Calendar Round for Long Count date 0.0.0.0.0
(or the equivalent 13.0.0.0.0), which are listed in this table:

Type

Symbol

Coordinate

Trecena

tr

4

Veintena

v

0

Haab

hb

-17 (or 348)

Armed with these starting point coordinates, you can calculate the exact Calendar Round
day for any given Long Count date of five coeffecients using just three formulae:

Formula 1: Finding the Veintena

In other words, the veintena day is always equal to the K’in
coeffecient of the LC date, where 0 = ’Ahaw and 19 =
Kawak. For our example of 0.0.0.0.1, the veintena day is
1, ’Imix.

Formula 2: Finding the Trecena

This formula is Lounsbury’s method for calculating the trecena position from Long Count dates
(Lounsbury, 1978 and Lounsbury, N.D.).
He observed that the trecena coeffecient moved, forward or backward, directly according to the days passed.
Each day that passed incremented or decremented the trecena by one,
each winal incremented or decremented by 20,
and so on. However, these shifts can be reduced by taking them modulo 13,
and if tr % 13 is 0, substitute 13;
therefore,
the real shift for the winal is either 7 or -6, depending on which you prefer to use (the distance between
the negative shift and the positive one must add to 13), being equivalent.
For tuns, the shift is either 9 or -4; for k’atuns,
11 or -2. This can be further simplified so that a table
of all shifts, both positive and negative, need not be kept for all positions in the Long Count
(bak’tuns, piktuns, and so on), but may instead be rather quickly calculated.
He observed that, except for the tun position, each shift is 7 times the shift of the position to its right.
In the tun position, the multiplier is 5 instead of 7, due to the odd radix (18 instead of 20).

For the ordinary Long Count date with five coeffecients, the following table of multipliers should suffice:

Period

Coeffecient (LC)

Trecena Multiplier (m)

K’in

0 (LC[0])

1

Winal

1 (LC[1])

-6 (or 7)

Tun

2 (LC[2])

-4 (or 9)

K’atun

3 (LC[3])

-2 (or 11)

Bak’tun

4 (LC[4])

-1 (or 12)

Basically, the procedure for calculating the trecena is fairly simple. You begin with
the trecena of your starting day, which for Long Count dates is 4 (as in 4 ’Ahaw),
and then starting with
the LC coeffecient for the K’in position, or LC[0] as shown in the table above,
multiply the coeffecient times the multiplier (again, from the above table) and add that
to your starting point; you then move to
the next position, and add your result to your total for position 0, and so on.
For these first five LC positions, then, the basic formula is:

Formula 3: Finding the Haab Position

Floyd made the same general observation about the haab;
for each day incremented or decremented from any starting point, the
haab position also incremented or decremented by 1.
For each winal, the haab position also moves 20
days, for each tun, it moved either 360 or -5
days, and so on.

The table below, covering Long Count dates with five coeffecients, shows the necessary
haab multipliers:

Period

Coeffecient (LC)

Haab Multiplier (mh)

K’in

0 (LC[0])

1

Winal

1 (LC[1])

20

Tun

2 (LC[2])

-5

K’atun

3 (LC[3])

-100

Bak’tun

4 (LC[4])

-175

In general, the procedure for calculating the haab position is the same as that for finding the trecena.
You start with -17, as that is that haab coordinate for 8 Kumk’u on LC0.0.0.0.0, and add
appropriate amounts for the number of days passed, forward or backward. You use the mh values in the table
above, and take the result modulo 365 instead of 13: