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 Modified Julian Day (MJD) is created by subtracting 2400000.5 from a Julian day number, and thus represents the number of days elapsed since midnight (00:00) Universal Time on November 17, 1858. Modified Julian Days are widely used to specify the epoch in tables of orbital elements of artificial Earth satellites. Since no such objects existed prior to October 4, 1957, all satellite-related MJDs are positive.
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.
by John Walker