Reset the XRS Calendar clocks on this page Check out the XRS Calendar's video channel on Planet YouTube! Check out the XRS Calendar's page on Planet Facebook! Check out the XRS Calendar's encyclopedia entry on Planet Wikipedia!
Right now it's   ISO 8601 Semblance:         Epochal Day:

Explore the XRS Calendar's
Date Conversion Demo

The Extended-Range Secular Calendar's date conversion apps are probably quite unlike any other such calendar conversion app on the Web. They're replete with a variety of interesting and unusual features. And even though the demo app on this page has limited functionality, you can still do a lot with it. You can convert from Gregorian dates1 to their equivalent XRS Calendar dates, and vice versa. The converter operates in both directions, and you can toggle between conversion modes without losing the date that you've entered. Try it: notice that the converter has already processed the date and time that this page was loaded. Click the button labeled Toggle, and watch the converter change color like a chameleon as it swaps conversion modes. Note too that the entire entry panel on the left has been replaced by a different panel. That's because the XRS Calendar is quite different from the Julian and Gregorian calendars, and requires different input functions as a result.

But wait—there's more, much more. You can input not only a date, but also the time of day. While in Julian/ Gregorian-to-XRS Calendar mode, you can convert a conventional sexagesimal time into decimal time. When you've toggled to XRS Calendar-to-Julian/Gregorian mode, you can convert from the decimal time back to the sexagesimal. Just be aware that entering a decimal time involves entering first the number of tenths of a day, followed by the number of thousandths of a day—and for real fine-tuning, hundred-thousandths of a day as well. Astronomers especially will find quite useful the buttons labeled 0h and 12h, which set the time to midnight and noon respectively regardless of the conversion mode in place. The 0h button comes in handy when you want to get rid of "visual noise" and work with dates only. You can also enter the current UTC date and time at any point in your session, simply by clicking the button labeled Now.

Now here's the best part: As you select a component of the date to be converted, the app converts the edited date on the fly, enabling you to view every intermediate result! Note that this conversion appears in four different formats: (1) Big-endian; (2) ISO 8601 (or a semblance thereof, if you're converting to XRS date and time); (3) Julian Day number and (4) Epochal Day number. Lastly, you can "save" your most important entries (in a manner of speaking; see the section titled Limitations of the Demo Version below), and track your stored results with the buttons labeled and . These buttons function similarly to "Undo" and "Redo" in other applications, walking you backward and forward through all your saved entries, recalling them to the display one-by-one.

Before you begin experimenting with this demo app, it's recommended that you roll your cursor over the various buttons and selectors. Unless their function is obvious, most of these devices will display a tooltip that tells you what that device is designed to do.

Epochs Entered Automatically

As if all that weren't enough, the demo app provides a large drop-down menu at the top that enables automatic entry of 36 important epochal dates, many of which are widely used by astronomers, anthropologists, historians, calendarists, and other scientists. These dates include the epochs of 18 calendars from around the world—including the XRS Calendar—and several artificial epochs created by scientists. Of the latter, some are reductions used by NASA, the SAO, and other organizations to truncate actual Julian Day numbers into more convenient abbreviations. All epochs herein are calculated for midnight UTC, except those marked "12h", which are calculated for noon.2

The Epochs selector also affords a number of novel landmark dates pertaining to the XRS Calendar. Of these, the most remarkable might just be the reduction that's labeled Reduced Year 7000 B. It so happens that when Undecimber 25 of the XRS year 7000 is converted to an Epochal day number, the trailing four digits comprise the number 7000! 3

Behaviors of the Converter

A Word about Selectors: If you have ever filled out a form online (and who hasn't?), you've no doubt used HTML selectors—those little drop-down/pop-up menus that allow you to select numeric or other data without typing manually. In most cases you would use each selector only once, then click a button labeled "Submit" or some such when you were finished. Sad to say, HTML selectors are not optimally designed for the repeated use that this demo app makes possible. There are two reasons for this. One is that HTML selectors respond only to changes in their current state; the other is that these selectors maintain their state until that state is changed once more.

But what does all that mean, in a real-world application? Let's say that you open this webpage, and the demo app displays the current date in the Gregorian year 2018. Let's assume you want to convert a date in the year 2000 instead. The Year selector already shows its default state of "00"; yet when you click on "00", nothing happens. That's because you haven't changed the current state of that selector; you have only re-selected its current state. To effect the selection that you want, you would have to change its state to, say, "01", then change again to "00". What's more, the Year selector will maintain this "00" state even if you've since changed the year dozens of times by means of other selectors and buttons—for instance, by using the Epochs selector, or the Now button.

The upshot, then, is this: If you want to use a selector to choose the state that it happens to be in already, just clicking on that state will not effect the choice that you want. You will have to first change to another selection, then change once more to your desired choice. This is a nuisance to be sure, but it's minor compared to the many benefits of using a conversion app such as this one.

Astronomical and Apparent Years: Because there is no zero year in the Julian Calendar, Julian years BCE ("Before the Current Era") are defined differently from astronomical years. Specifically, 1 BCE is equivalent to astronomical year 0; 2 BCE is equivalent to astronomical year -1; 100 BCE is the equivalent of -99 in astronomical years; and so on. The formula for converting a BCE year (rendered as a positive number) to an astronomical year, and vice versa, is as follows: Astronomical Year = 1 - BCE Year However, when editing a Julian date BCE, you don't have to convert to the equivalent astronomical year. Just enter the year as it appears BCE; for example, to enter 4000 BCE, select "4000 BCE" using the Century selector, and "00" using the Year selector. The converter will represent this year internally as the astronomical year -3999. To enter any year from 1 to 99 CE, first select "1 to 99 CE" from the Century selector, then select the year of choice from the Year selector. Similarly, to enter any year from 99 to 1 BCE, first select "99 to 1 BCE" from the Century selector, then the year as before. Either way, if you happen to select "00" using the Year selector, the converter recognizes that there is no such selection, and will default to either 1 CE or 1 BCE as appropriate.

A similar though converse behavior emerges when you're editing an XRS Calendar date for conversion. Let's say you've toggled to the XRS Calendar-to-Julian/Gregorian side (in blue), and you've entered "-99 to -1" from the Century selector, and "00" from the Year selector. Because zero cannot be interpreted as a negative number, the converter will default to the XRS year 0.

Entry Validation: In converters of this type it is possible to enter a date that is patently invalid—for example, April 31, or February 30 in the Julian and Gregorian Calendars. However, rather than displaying error messages, this app performs corrective actions quietly and automatically. April 31 will instantly be corrected to April 30; February 30 or 31 will be adjusted to February 28 in common years, and February 29 in leap years of the Proleptic Julian or Gregorian Calendar as appropriate. Similarly, if you're entering XRS dates in the Intercalary period, and you make an invalid entry such as Intercalary 3, or Intercalary 25, the converter will adjust the entry to Intercalary 1 in common XRS years, and Intercalary 2 in leap years. Further, these corrections will be made on the fly, even if you don't enter an invalid date deliberately. For instance, if December 31 is the active Gregorian date, and you switch to the month of September, the converter will adjust to show September 30; if February 29, 2012 is the active date, and you switch to a common year, February 28 will be displayed instead.

Another, much-less-obvious possibility is the entry of any date from October 5 through October 14, 1582 CE in the Julian and Gregorian Calendars. Why? Because these dates do not exist in either calendar! These are the dates skipped over by papal decree during the transition from the Julian to the Gregorian Calendar in 1582, a move deemed necessary in order to get the calendar date of the northward equinox closer to March 21. Try entering any of these nonexistent dates, and see what happens.

One other possibility of entering an invalid date remains: that's the attempt to enter a date that falls outside the range of acceptable dates for conversion purposes. These are covered in the section just below.

Date Delimiters: Because converting dates deep into the distant past or future—say, tens of thousands of years in either direction—is virtually a matter of pure speculation, the converter is equipped with date delimiters. These delimiters prohibit entry of any date with a Julian Day number less than -1383056.5, or greater than 5377211.49999. The lower limit translates to 8500 BCE May 26 00:00:00 UTC in the Proleptic Julian Calendar; in the XRS Calendar, this limit is equivalent to -3533 March 1.00000. The upper Julian Day limit of 5377211.49999 translates to 10010 March 15 23:59:59 UTC in the Gregorian Calendar, of which 14975 Intercalary 2.99999 is the XRS equivalent. That said, if you happen to go beyond these limits when you use the selectors, then in most cases the delimiters act very conservatively, adjusting your inputs only as necessary while preserving much of the data that you've already entered.

Limitations of the Demo Version

Range of Conversion: By now you probably will have noticed that, while you can use the selectors and buttons to enter any date and time within the more-than-18,500-year range of this converter, the demo version on this page will permit conversions only from January 1, 1800 through December 31, 2100 Gregorian. Naturally, this is in order to give users ample opportunity to see how the converter works in general, but without "giving away the entire farm." If you occasionally exceed its allowable 301-year range, the demo app displays an advisory message in red, and will be partially disabled so as to disallow unwarranted conversion of dates that are outside this range. Specifically, the demo won't allow toggling or saving of out-of-range dates, and on the XRS Calendar-to-Julian/ Gregorian side, the Epochs selector will not make available any epoch that is out of range. Generally speaking, there are three ways to get out of this jam: (1) You can use the selectors and buttons to input a date that is within range, and the converter will "unlock" itself; or (2) You can cycle through your saved entries using the and buttons; or (3) The easiest way out is to click the link labeled Continue within the advisory. If you do, the app will be reset to the saved entry that was most recently displayed (and not necessarily the entry most recently saved). If no entries have been saved, the app will be reset to the current UTC date and time instead.

Nevertheless, readers will soon be able to exploit the full range of conversions from 8500 BCE through 10010 CE (Proleptic Julian and Gregorian respectively). In the coming months, native versions of this date conversion app will be produced for mobile devices such as smartphones and tablets, and eventually, desktop and laptop computers. The date converter will be conjoined with unrestricted versions of the calendar demo, the day-of-week conversion demo, and a datebook feature for logging important events in terms of both the XRS and Gregorian calendars.

Saving Entries: If you've used the Save button across different sessions, you may also have noticed that it does not really "save" in the strict sense of making your entries persist across sessions, by saving them to a file. Rather, this demo version merely places your saved entries into a temporary queue that remains in place only while this webpage is open. After the page has been closed, or reloaded to your browser, the queue is eradicated and your saved entries will be lost. Again, this limitation will be obviated by the native apps, which will save your entries to the files of your choice, locally on your own device.

Some Provisos Concerning Accuracy

The XRS Calendar's date conversion methods are predicated on two important assumptions. One is that the Gregorian Calendar will survive for some time into the future, and if not, will inevitably be projected into the future for purely academic purposes. The other is that no adjustment will be made to the Gregorian Calendar for purposes of realigning seasonal points with the 20th, 21st, or 22nd day of their respective months. This website cannot speak to the issue of how, or when, the Gregorian Calendar might be adjusted in the future;4 however, it seems rather unlikely that the calendar won't be adjusted if it persists to any significant degree. Remember that the Gregorian Calendar is less than 435 years old as of this writing. That's far too little time for subtle yet critical flaws in the calendar's design to reveal themselves by happenstance. Once you have on hand an unrestricted date converter, you will see in very short order that the Gregorian Calendar will begin to slip, rather harmlessly though nonetheless badly, as the millennia wear on—notwithstanding the 16th-century Vatican Council's best attempts to prevent such slippage from occurring. If agronomists care at all about keeping seasonal dates from drifting over thousands of years—or if high priests of the Church care about keeping their Easter calculations more or less uniform throughout the centuries—then some future adjustment of the Gregorian Calendar will have to take place—perhaps as soon as 3200 CE.

Likewise, since the XRS Calendar is also an arithmetical calendar (albeit a highly sophisticated one), it too is subject to possible revision in the future just in case the astronomical observations of that time are found to be at odds with what we had predicted many centuries previously. Therefore, wherever one calendar undergoes revision without the other following suit, whole series of conversions will inevitably be thrown off by one day, or even more. A converter like the one presented here embodies a kind of steeplechase between two competing visions: which arithmetical schema will eventually track future occurrences of the northward equinox more precisely, and hew more closely to changes in the mean northward equinoctial year? Once the design of the XRS Calendar becomes more "embedded" culturally, with native versions of the calendar implementation available on the marketplace, this website will provide a thoroughgoing case for the XRS Calendar's accuracy, making the most of the very best astronomical data that humanity currently has on hand.

Notes

1. Albeit within a limited range, as you'll soon see. Consistent with everything else on this website, the Date Conversion demo is based on the Proleptic Julian Calendar for all dates prior to and including October 4, 1582 CE, and on the Gregorian Calendar for all dates from October 15, 1582 CE forward.

2. Epochs of the 18 calendars are mostly from Nachum Dershowitz and Edward M. Reingold, Calendrical Calculations, 3rd ed. (Cambridge University Press, 2008), p. 15. Other epochs are cited in this entry in Wikipedia. Following the convention established by Dershowitz and Reingold, every calendar's epoch is herein taken to occur at midnight UTC of the civil day containing the first noon of the epochal day, even if the days of that calendar do not literally begin and end at midnight (p. 14). For example, the first Hebrew day actually began at local sunset, October 6, 3761 BCE (Proleptic Julian Calendar), not midnight, October 7.

It should be added that every epoch in the drop-down assumes a Day 0 at the origin, not Day 1. This may cause some confusion where Rata Die (the fixed date used by Dershowitz and Reingold almost to the exclusion of everything else) is concerned. They define R.D. 1 as having occurred on Monday, January 1, 1 CE (Proleptic Gregorian, p. 10), equivalent to Monday, January 3 in the Proleptic Julian Calendar used here. But this yields a starting JD of 1721425.5, one day more than the 1721424.5 cited by Dershowitz and Reingold, and other authors universally. So this author infers that they too are implicitly using a Day 0 as their starting point. Accordingly, the Epochs drop-down cites Sunday, January 2, 1 CE (Proleptic Julian) as the Rata Die epoch.

3. Not a deliberate decision, and the choice of epoch for the XRS Calendar is certainly not based on it. This is just a remarkable numeric coincidence—nothing more.

4. Indeed, some proposals for adjusting the Gregorian Calendar have already come down the pike. According to this Wikipedia entry, "In the 19th century, Sir John Herschel [who originated the use of the Julian Day system in astronomy] proposed a modification to the Gregorian calendar with 969 leap days every 4000 years, instead of 970 leap days that the Gregorian calendar would insert over the same period. This would reduce the average year to 365.24225 days [from 365.2425]. Herschel's proposal would make the year 4000, and multiples thereof, common instead of leap. While this modification has often been proposed since, it has never been officially adopted."

It's not hard to see why proposals such as this one have never been adopted. As good as it is, Herschel's scheme is yet another static algorithm that doesn't adapt to long-term changes in the length of the mean northward equinoctial year (MNEY). As it stands, this algorithm generates a year of 48 minutes, 50.4 seconds in excess of 365 days, five hours—a definite improvement over the 49 minutes, 12.0 seconds of the Gregorian leap-year cycle, which is already too long. But compare Herschel's proposal against Dr. Irv Bromberg's graph showing a linear approximation to the MNEY over time. Consider too that the first three occurrences of a Herschel leap year would go into effect in the years 4000, 8000, and 12000. According to Dr. Bromberg's analysis, the year-4000 occurrence would nicely undercut the estimated MNEY of 48 minutes, 58 seconds, allowing drift-free performance through about 5200. But afterward, Herschel's proposal would not only be ineffective; it would be calamitous. By the year 8000, the MNEY is expected to shorten to 48 minutes, 10 seconds...and by 12000, to 46 minutes, 55 seconds. That's nearly two minutes shorter than the cycle yielded by Herschel's proposal!