Welcome to Fourmilab's calendar converter! This page allows you to interconvert dates in a variety of calendars, both civil and computer-related. All calculations are done in JavaScript executed in your own browser; complete source code is embedded in this page, and you're free to save the page into a file on your own computer and use it even when not connected to the Internet. To use the page, your browser must support JavaScript and you must not have disabled execution of that language. Let's see...

If the box above says "Your browser supports JavaScript", you're in business; simply enter a date in any of the boxes below and press the "Calculate" button to show that date in all of the other calendars.

The Gregorian calandar is a minor correction to the Julian. In the
Julian calendar every fourth year is a leap year in which February has
29, not 28 days, but in the Gregorian, years divisible by 100 are
*not* leap years unless they are also divisible by 400. How
prescient was Pope Gregory! Whatever the problems of Y2K, they won't
include sloppy programming which assumes every year divisible by 4 is
a leap year since 2000, unlike the previous and subsequent years
divisible by 100, *is* a leap year. As in the Julian calendar,
days are considered to begin at midnight.

The average length of a year in the Gregorian calendar is 365.2425 days compared to the actual solar tropical year (time from equinox to equinox) of 365.24219878 days, so the calendar accumulates one day of error with respect to the solar year about every 3300 years. As a purely solar calendar, no attempt is made to synchronise the start of months to the phases of the Moon.

A slight modification of the Gregorian calendar would make it even more
precise. If you add the additional rule that years evenly divisible
by 4000 are *not* leap years, you obtain an average solar year
of 365.24225 days per year which, compared to the actual mean year
of 365.24219878, is equivalent to an error of one day over a period
of about 19,500 years; this is comparable to errors due to tidal
braking of the rotation of the Earth.

While any event in recorded human history can be written as a positive Julian day number, when working with contemporary events all those digits can be cumbersome. A

In the Julian calendar the average year has a length of 365.25 days.
compared to the actual solar tropical year
of 365.24219878 days. The calendar thus accumulates one day of
error with respect to the solar year every 128 years.
Being a purely solar calendar, no attempt is made to synchronise the
start of months to the phases of the Moon.

Years are classified as *common* (normal) or
*embolismic* (leap) years which occur in a 19 year
cycle in years 3, 6, 8, 11, 14, 17, and 19. In an
embolismic (leap) year, an extra *month* of 29 days,
"Veadar" or "Adar II", is added to the end of the year after
the month "Adar", which is designated "Adar I" in such
years. Further, years may be *deficient*,
*regular*, or *complete*, having respectively
353, 354, or 355 days in a common year and 383, 384, or 385
days in embolismic years. Days are defined as beginning at
sunset, and the calendar begins at sunset the night before
Monday, October 7, 3761 B.C.E. in the Julian calendar, or
Julian day 347995.5. Days are numbered with Sunday as day 1,
through Saturday: day 7.

The average length of a month is 29.530594, extremely close
to the mean *synodic month* (time from new Moon to
next new Moon) of 29.530588 days. Such is the accuracy that
more than 13,800 years elapse before a single day
discrepancy between the calendar's average reckoning of the
start of months and the mean time of the new Moon.
Alignment with the solar year is better than the Julian
calendar, but inferior to the Gregorian. The average length
of a year is 365.2468 days compared to the actual solar tropical
year (time from equinox to equinox) of 365.24219 days, so
the calendar accumulates one day of error with respect to
the solar year every 216 years.

Each cycle of 30 years thus contains 19 normal years of 354
days and 11 leap years of 355, so the average length of a
year is therefore ((19 × 354) + (11 × 355)) / 30 =
354.365... days, with a mean length of month of 1/12 this
figure, or 29.53055... days, which closely approximates the
mean *synodic month* (time from new Moon to next new
Moon) of 29.530588 days, with the calendar only slipping one
day with respect to the Moon every 2525 years. Since the calendar
is fixed to the Moon, not the solar years, the months shift
with respect to the seasons, with each month beginning about
11 days earlier in each successive solar year.

The calendar presented here is the most commonly used
civil calendar in the Islamic world; for religious purposes
months are defined to start with the first observation of
the crescent of the new Moon.

As one of the few calendars designed in the era of accurate
positional astronomy, the Persian calendar uses a very complex
leap year structure which makes it the most accurate solar
calendar in use today. Years are grouped into *cycles*
which begin with four normal years after which every fourth
subsequent year in the cycle is a leap year. Cycles are grouped
into *grand cycles* of either 128 years (composed of
cycles of 29, 33, 33, and 33 years) or 132 years, containing
cycles of of 29, 33, 33, and 37 years. A *great grand
cycle* is composed of 21 consecutive 128 year grand cycles
and a final 132 grand cycle, for a total of 2820 years. The
pattern of normal and leap years which began in 1925 will not
repeat until the year 4745!

Each 2820 year great grand cycle contains 2137 normal
years of 365 days and 683 leap years of 366 days,
with the average year length over the great grand cycle
of 365.24219852. So close is this to the actual
solar tropical year of 365.24219878 days that the
Persian calendar accumulates an error of one day
only every 3.8 million years. As a purely solar
calendar, months are not synchronised with the
phases of the Moon.

The ISO week calendar is a derivative of the Gregorian calendar
and shares its accuracy.

The machines on which Unix was developed and initially deployed
could not support arithmetic on integers longer than 32 bits
without costly multiple-precision computation in software.
The internal representation of time was therefore chosen to be
the number of seconds elapsed since
00:00 Universal time on January 1, 1970 in the Gregorian
calendar (Julian day 2440587.5), with time stored as a 32
bit signed integer (`long` in the original C implementation).

The influence of Unix time representation has spread well
beyond Unix since most C and C++ libraries on other systems
provide Unix-compatible time and date functions. The major
drawback of Unix time representation is that, if kept as a
32 bit signed quantity, on January 19, 2038 it will go
negative, resulting in chaos in programs unprepared for
this. Modern Unix and C implementations define the result
of the `time()` function as type `time_t`,
which leaves the door open for remediation (by changing the
definition to a 64 bit integer, for example) before the
clock ticks the dreaded doomsday second.

You'd be entitled to think, therefore, that conversion back and
forth between PC Excel serial values and Julian day numbers would
simply be a matter of adding or subtracting the Julian day number
of December 31, 1899 (since the PC Excel days are numbered from 1).
But this is a *Microsoft* calendar, remember, so one must
first look to make sure it doesn't contain one of those bonehead
blunders characteristic of Microsoft. As is usually the case,
one doesn't have to look very far. If you have a copy of PC
Excel, fire it up, format a cell as containing a date, and
type 60 into it: out pops "February 29, 1900". News apparently
travels *very* slowly from Rome to Redmond--ever since
Pope Gregory revised the calendar in 1582, years divisible
by 100 have *not* been leap years, and consequently the
year 1900 contained no February 29th. Due to this morsel of
information having been lost somewhere between the Holy See and
the Infernal Seattle monopoly,
all Excel day numbers for days subsequent to February 28th, 1900
are one day greater than the actual day count from January 1, 1900.
Further, note that any computation of the number of days in
a period which begins in January or February 1900 and ends in a
subsequent month will be off by one--the day count will be one
greater than the actual number of days elapsed.

By the time the 1900 blunder was discovered, Excel users had
created millions of spreadsheets containing incorrect
day numbers, so Microsoft decided to leave the error in place
rather than force users to convert their spreadsheets, and the
error remains to this day. Note, however, that *only 1900*
is affected; while the first release of Excel probably also
screwed up all years divisible by 100 and hence implemented a
purely Julian calendar, contemporary versions do correctly
count days in 2000 (which is a leap year, being divisible by
400), 2100, and subsequent end of century years.

PC Excel day numbers are valid only between 1 (January 1, 1900) and
2958465 (December 31, 9999). Although a serial day counting scheme
has no difficulty coping with arbitrary date ranges or days before
the start of the epoch (given sufficient precision in the representation
of numbers), Excel doesn't do so. Day 0 is deemed the idiotic
January 0, 1900 (at least in Excel 97), and negative days and
those in Y10K and beyond are not handled at all. Further, old
versions of Excel did date arithmetic using 16 bit quanitities
and did not support day numbers greater than 65380 (December
31, 2078); I do not know in which release of Excel this
limitation was remedied.

Macintosh Excel day numbers are valid only between 0
(January 1, 1900) and 2957003 (December 31, 9999). Although
a serial day counting scheme has no difficulty coping with
arbitrary date ranges or days before the start of the epoch
(given sufficient precision in the representation of
numbers), Excel doesn't do so. Negative days and those in
Y10K and beyond are not handled at all. Further, old
versions of Excel did date arithmetic using 16 bit
quanitities and did not support day numbers greater than
63918 (December 31, 2078); I do not know in which release of
Excel this limitation was remedied.

- Meeus, Jean. Astronomical Algorithms . Richmond: Willmann-Bell, 1991. ISBN 0-943396-35-2.
- The essential reference for computational positional
astronomy.

by John Walker

December, MIM