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.
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.0 Initial 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.
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.
Since both the Long Count and the Julian Period are rigid daycounting 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 “n_{0}.n_{1}.n_{2}.n_{3}.n_{4}” 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, n_{4}, 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 n_{1} (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, 5place, Long Counts:
Period  Place  Number of Days  Tun^{n} 

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!).
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 modulo 20; to find the value of n_{i}, we need to use the radix for n_{i + 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 / 20
total = 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.
q=1356840 # Our number lst=[] # Our output list, the Mayan date bs=20 # Radix of the current position i=0 # Index of the current position r=0 # Remainder if q==0: # We need to special case 0 lst.append (0) print lst else: while q>0: if i==1: bs=18 else: bs=20 r=q%bs lst.append(r) q=q/bs i=i+1 lst.reverse() # Reverse the list; store k'in first print lst 
When we run the program, the output is:
[9, 8, 9, 0, 0]
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.
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.
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: v=LC[0] Formula 2: tr=(4 + ((LC[0] · 1) + (LC[1] · 6) + (LC[2] · 4) + (LC[3] · 2) + (LC[4] · 1))) % 13 Formula 3: hb=(17 + ((LC[0] · 1) + (LC[1] · 20) + (LC[2] · 5) + (LC[3] · 100) + (LC[4] · 175))) % 365 
v = LC[0]
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.
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:
tr = (4 + ((LC[0] · m[0]) + (LC[1] · m[1]) + (LC[2] · m[2]) + (LC[3] · m[3]) + (LC[4] · m[4]))) % 13
For our example (0.0.0.0.1), we can plug in the appropriate values:
tr = (4 + ((1 · 1) + (0 · 6) + (0 · 4) + (0 · 2) + (0 · 1))) % 13
tr = (4 + ((1) + (0) + (0) + (0) + (0))) % 13
tr = (4 + (1)) % 13
tr = (5) % 13
tr = 5
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 LC 0.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:
hb = (17 + ((LC[0] · mh[0]) + (LC[1] · mh[1]) + (LC[2] · mh[2]) + (LC[3] · mh[3]) + (LC[4] · mh[4]))) % 365
For our example (0.0.0.0.1), we can plug in the appropriate values:
hb = (17 + ((1 · 1) + (0 · 20) + (0 · 5) + (0 · 100) + (0 · 175))) % 365
hb = (17 + ((1) + (0) + (0) + (0) + (0))) % 365
hb = (17 + (1)) % 365
hb = (16) % 365
hb = 349
Since we only have the haab position, we need to convert that, using the usual formulae, to a haab day and haab month:
haabmonth = (int) hb / 20
haabmonth = 349 / 20
haabmonth = 17
haabmonth = Kumk’u (Pohp is month 0)
haabday = hb % 20
haabday = 349 % 20
haabday = 9
So our full Calendar Round day for the Long Count date 0.0.0.0.1 is 5 ’Imix 9 Kumk’u.
(And for anyone who cares, the full Calendar Round date for 9.8.9.0.0, which we used in our earlier examples, is 8 ’Ahaw 18 Xul.)



Main web site: http://www.pauahtun.org