Steve's Julian Date Calculator

The form above is initialised to the universal date and time (to all intents and purposes, this is the same as Greenwich Mean Time, but not exactly the same - see differences), as determined by the clock in your computer at the time this page is entered (Note: this is always to the nearest second).  A conversion from your local timezone is applied.

The clock above the form shows current universal time according to Time and Date’s server clock, and will keep ‘ticking’. 

The time shown in the form will not ‘tick’ - this and the date are free for you to alter as inputs to the Julian date calculator. 

Fields that have a blue/grey background are read-only.  The weekday field is determined from the Julian date and the timezone field is fixed according to the local date and time when your session was started.  This includes any correction for ‘daylight saving’ (or ‘Summer Time’).

CE and BCE designate “Common Era” and “Before Common Era”, often known as “AD” and “BC” respectively.  See notes below for the use year zero option.

The UNIX Time Stamp is used in the ‘C’ programming language and for showing cookie expiry dates in Mozilla Firefox, among other things.  It is defined as the number of seconds since 1970-Jan-01 00:00:00 UTC.  It is often set to be a 32-bit integer; if so, fractions are truncated.  If set to be an unsigned integer, a system will not handle times before 1st January 1970 correctly, and the last time that will be expressed properly will be 2106-Feb-07 06:28:15 UTC.  Of more concern might be software using a signed integer, whereby a ‘Y2K’ type bug will cause failure after 2038-Jan-19 03:14:07 UTC.  However, this calculator shows all positive times correctly, plus fractions (to the nearest 10ms).  Times before 1970 are shown as negative.

File Time (MFT) is a 64-bit integer used by Microsoft to show the number of 100ns ‘ticks’ since 1601-Jan-01 00:00:00 UTC.  It is often split into two 32-bit integers (high and low halves), each of which is expressed in decimal form, as in this calculator.  It is principally used in Internet Explorer cookies to denote expiry and creation times, and also for time stamping files in NTFS file systems, such as are used in Windows 2000 and later.  The MFT 64-bit integer will overflow in the year 60056, so it will be valid for the forseeable future!  Since the ‘tick’ is only 100ns, which is 1/100000th of 10ms (the maximum resolution of this calculator), the 5 least significant figures in the low integer are meaningless here, so they are set to zero.  Also, since MFT cookies before 1601 CE would be a bit stale, negative results are not given.

Whilst the UNIX start date in 1970 seems sensible, given that the ‘C’ programming language was developed in the early 1970’s, it’s a mystery why Microsoft chose 1601 for the MFT - though this is not the only mysterious thing about Microsoft!  [Wikipedia gives a somewhat tenuous reason, in my view, that this date was chosen because it was the beginning of the 400-year Gregorian leap-year cycle within which digital files first existed.]  NB: If decoding cookie expiry time using this calculator, the time given might differ from that reported by the browser by a few hours.  This will be due to the difference between local time and UTC when the cookie is set to expire.  [It is a feature of MFT that the value is stored as UTC, but is translated to local time when displayed.  Keeping everything in UTC means it is impossible for a cookie or file to be read before it was written - something that could happen to files transmitted over the Internet between different timezones if local times were used.]

The Mayan Long Calendar day is shown here (as read-only) because the date 2012-Dec-21 was significant.  On this date, the second box from the left (b’ak’tun) rolled over to 13, which was the same Mayan date as the start of the Fourth Creation.  Because of this, and almost certainly because it was also the northern winter solstice, some prophets of doom reckoned the world would end on that day.  All this is explained at length by Wikipedia.  Well, the world didn't end then: the Maya philosophy was instead that a re-creation would take place.  Let’s hope the Fifth Creation starts better than the Fourth ended....

Note that Mayan scholars and astronomers disagree about the use of the Julian Calendar for dates in the past (Mayan scholars treat all ‘conventional’ calendar dates in the past as Gregorian, using the ‘Proleptic Gregorian Calendar’).  Therefore dates before the Gregorian change (in 1582) that are given in the Wikipedia article differ from those calculated here.  To concur with the Wikipedia article, the b’ak’tun value is never zero for dates in the past: the start of the Fourth Creation (JD 584283) is notated as 13.0.0.0.0, and the next b’ak’tun (1.0.0.0.0 = JD 728283) started after 13.19.19.17.19 (JD 728282).  Previous roll-overs had b’ak’tun values between 1 and 13.  To concur with Mayan scholars’ representation of future dates, the b’ak’tun figure will now go up to 19 and then roll over to zero, when the next most significant figure (piktun) becomes a 1.  Although the piktun will also roll over to 0 after 19.19.19.19.17.19, for simplicity, this calculator will allow it to increase beyond 19 (19.19.19.19.17.19 will be JD 58184282 or 154591-Feb-27).
 

This utility is based on a calculator that was originally published by the astronomical applications department of the US Naval Observatory, but that version did not handle local times east of London properly.  However, the contents of that site (and URLs within it) keep on changing, quickly rendering out-of-date any link I put here.  Hence the link above is only to their home page: if you want to see how they do it now, have a look for it on their site (but please come back here!).

This calculator uses the original format to convert from calendar date and time to Julian Date, and vice versa.  The direction of conversion is selected by the calculation type.  This page and its associated JavaScript file have been extended by Steve Glennie-Smith to increase accuracy to the nearest 10ms.  Other extras include a ‘ticking’ UTC clock; calculation of and from UNIX time stamp and Microsoft File Format; and showing the local timezone and the Mayan long calendar date.  Bug fixes are listed at the end.

Julian dates (abbreviated JD) are simply a contiguous count of days and fractions since noon Universal Time on 1st January, 4713 BCE (on the Julian calendar).  Almost 2.5 million days have elapsed since that date.  Julian dates are widely used as time variables in astronomical software.  Typically, a 64-bit floating point (double precision) variable can represent an epoch expressed as a Julian date to about 1 millisecond precision.  Note that the time scale that is the basis for Julian dates is Universal Time, and that 00:00h UTC always occurs at a Julian date fraction of 0.5.  The distinction between Julian date and Julian day is that the former is the whole number, including the fractional part, whereas the latter is just the integer part, ie. the number of days since ‘day zero’.

Why was January 1st 4713 BCE chosen as the starting point?  Some theories here.
 

---

Calendar dates – year, month, and day – are even more of a problem.  Various calendar systems have been in use at different times and places around the world.  This calculator deals with only two: the Gregorian calendar, now used universally for civil purposes, and the Julian calendar, its predecessor in most of the western world.  As used here, the two calendars have identical month names and number of days in each month; they differ only in the rule for leap years.  The Julian calendar has a leap year every fourth year, while the Gregorian calendar has a leap year every fourth year except centennial years that are not exactly divisible by 400.

Although JD zero was 1st January 4713 BCE, this calculator will allow negative Julian Dates, and years with up to six figures.

The following assumptions are made:

• Weeks have always had seven days, named as now, since time began.  Thus, the day of the week can be obtained from the remainder, after dividing the Julian date (plus the 0.5 day offset, but then expressed as an integer) by 7 (0 corresponds to Monday);
• the Julian calendar had no year 0.  Therefore, 0001-Dec-31 BCE (or BC) was immediately followed by 0001-Jan-01 CE (or AD).  However, some astronomers do recognise a year 0.  If this variation is required, tick the ‘Use Year Zero’ checkbox;
• The Julian calendar is assumed always to have had leap years.  Since it had no year 0, years 1, 5, etc. BCE are considered to be leap years by this calculator (if use year zero is unchecked).  However, some research (see below) indicates that before the introduction of the Julian calendar in 45 BCE, there was no consistency in the number of days in each year;
• This calculator does not take leap seconds into account.  Since 00:00h UTC always occurs at a Julian date fraction of 0.5, it is assumed that the fractional part (which represents hours, minutes, seconds and parts thereof) of Julian dates where a leap second is inserted must be ‘stretched’ on such dates.  Therefore calculations made for such dates will be inaccurate by up to one second.  Since leap seconds are only inserted (or theoretically, they could be deleted) at midnight UTC, this will always occur at the middle of a Julian day.  (Note: The purpose of a leap second is to correct for slight variations in the time it takes for the earth to rotate on its axis.  This has no bearing on the number of days it takes for the earth to orbit the sun, nor any correction for variations in this as applied by the Gregorian calendar);
• The changeover from the Julian calendar to the Gregorian calendar occurred in October of 1582, in accordance with a Papal Bull issued by Pope Gregory XIII.  Specifically, for dates on or before 4th October 1582, the Julian calendar is used; for dates on or after 15th October 1582, the Gregorian calendar is used.  Thus, there is a ten-day gap in calendar dates, but no discontinuity in Julian dates or days of the week: 4th October 1582 (Julian) was a Thursday, which began at JD 2299159.5; and 15th October 1582 (Gregorian) was a Friday, which began at JD 2299160.5.  It was necessary to delete ten calendar dates owing to the error accumulated by the Julian calendar: over many centuries of use, there had been too many leap years.
  The number of days omitted was chosen to resynchronise with the year 325 CE, the year in which Christian bishops met in Nicaea (modern İsnik, in Turkey).  Among items decided was that Easter Sunday would fall during the first full moon after the vernal (March) equinox (or if that day was a Sunday, Easter would be the following Sunday).  This was based on the Crucifixion having taken place during the Jewish Passover festival, itself being timed to coincide with that full moon.

The changeover to the Gregorian calendar only occurred as described above in Roman Catholic countries, however.  Adoption of the Gregorian calendar in the rest of the world progressed slowly.  For example, Great Britain and its colonies did not implement the change until September 1752 (though there is some doubt as to when the change took place in Scotland).  [The UNIX CAL command reflects the 1752 changeover, when it became necessary to delete eleven days, since the year 1700 had also been taken as a leap year.]

This produced some interesting anomalies.  For example, the Spanish author Miguel Cervantes and the English playwright William Shakespeare both died on the same date (23rd April 1616), but not the same day!  This is because Spain had adopted the Gregorian calendar but England had not yet done so.

The corrections applied by the Gregorian calendar give a close average approximation (365.2425 days) to the time it takes for the earth to orbit the sun.  However, the actual time taken (averaged over the last few centuries) is 365.242189 days, so a small error still accrues, though now it is only a gain of 1 day in about 3220 years.  It is necessary to average the time taken to orbit the sun over many years because the exact length can vary by up to 30 minutes, owing to effects caused by gravity of other planets.

Various extensions to the 100 and 400 year rules in the Gregorian calendar have been proposed, but none have officially been adopted:

• A 4000 year rule: Astronomer John Herschel suggested that if the year is divisible by 4000 it should not be a leap year.  This gives a better approximation by having 969 leap years in every 4000 (not 970), giving an average year of 365.24225 days.  Although not the most accurate of the proposed corrections, it falls neatly within the 4 - 100 - 400 sequence.  The UNIX CAL command includes this correction.
• A 3200 year rule, similar to the 4000 year rule above: This is much closer to addressing the 3220 year discrepancy, but seems to have little support outside the military.  The average corrected year would be 365.2421875 days.
• A 128 year rule: This does away with the 100 and 400 year rules altogether.  The proposal is to drop February 29th for years divisible by 128, commencing in 2048.  It is as accurate as the 3200 rule and the correction is applied more evenly.  It could be implemented at any time before 2048 without need for resynchronisation because the required number of ‘non-leap-years’ have already been omitted.  [1920 would not have been a leap year but 1900 would have been; likewise 1792 ~ 1800 and 1664 ~ 1700.  1536 and earlier were in the Julian era, and so wouldn’t have been affected.]  Although great for computer geeks and those who love powers of 2, it would not be so easy for ordinary mortals to handle.  Since I will be 100 in 2048, if I’m still around then, I could expect my royal telegram a day earlier if this system is adopted in the mean time!
• A 900 year rule: This has been proposed by the Greek Orthodox church.  It does away with the 400-year rule and instead makes years that leave a remainder of 200 or 600 when divided by 900 become leap years.  The average corrected year length would be 365.242222 days.  Both this and the Gregorian system give 2000 and 2400 as leap years.  Differences start in 2800, which would not be a leap year in the Greek system, but 2900 would be.

In my view, it would be churlish to impose changes that would take place so far ahead on future generations.  Who knows – some idiot might let off an atom bomb or the earth could be hit by a big meteorite, both of which could affect the length of the year, and so blow all this theory out of the water.  However, Julian dates will keep plodding along regardless.  Since the aim of this calculator is to give an accurate correlation between Julian dates and calendar dates way into the future, I have concurred with Herschel and UNIX, and altered the original JavaScript to include the 4000 year rule.

More information on when various countries changed can be found on the calendar pages of this European history site.  For another list of when certain countries switched to the Gregorian calendar, see section 2.2.4 of Claus Tøndering’s calendar FAQ.

More information on calendars and their histories can be found in L.E. Doggett’s “calendars” chapter of the explanatory supplement to the astronomical almanac (ed. P.K. Seidelmann, 1992, University Science Books).  Note: These are commercial booksellers’ sites.
 

Note: There are a number of other Julian date calculators on the web: a quick search on Google turned up this one, which works very slowly and gets confused by BCE dates.  It assumes (like a number of others) that all calendar dates are Gregorian and, according to it, JD zero was BCE4712 (month 0) (day -2)!  I did have a link to a worse one, that got it wrong before 1800 and after 2100 CE.  It’s since gone, but there are probably others.  Beware!
 

---