It's a Web page on which you can enter a date, time, and geographic location, and it will generate an astrological chart corresponding to that information. Normally one would use the data for a person's birth, though there's nothing in the system that requires that. The system supports a bunch of options for exactly how to draw the chart, and offers a variety of asteroids and minor planets. It computes the astrological information with Swiss Ephemeris and uses LaTeX with the horoscop and starfont packages to generate the output in PDF or PNG format.
Please do email me if you have suggestions for other features you'd like to see included in this service. I can't promise to implement them all, but if it's something simple like adding an object of interest, I'd be happy to get the request.
Many people like the free chart service at astro.com. It provides some interpretation information, and a wider range of types of chart. That service is probably better suited to end-users than mine. I think the charts from my software are better-looking on the page, though.
This service does not provide interpretation at all, only charts. Take it to an astrologer, or learn to interpret it yourself.
I like the astrology lessons section on Bob Marks's Web site.
It is not possible to provide any meaningful compatibility assessment based on just the people's Sun signs like that. At the very least you need the Moon signs as well - which require specific birthdates and at least approximate times of day. Elsewhere on this site I provide a quick-and-dirty compatibility test using Sun and Moon signs, but understand that that also is a very rough approximation.
That wasn't a question. However: Ophiucus is an astronomical constellation, not an astrological sign. Saying that Ophiucus ought to be included in astrology because astronomers use it is like saying that the alphabet for present-day English ought to include the letters thorn and eth because writers of Icelandic use those.
Enter the decimal degrees in the "degrees" boxes and leave the minutes and seconds at zero. You can also enter degrees and decimal minutes, leaving the seconds as zero. Either will be converted and displayed as degrees, minutes, and seconds.
Do not enter a sign (+ or -) on the degrees; that must still be indicated as North, South, East, or West with the dropdown boxes. This is to avoid taking a position on the contentious issue of which direction the longitude signs go.
This kind of thing does not work for the time: that must be entered in hours, minutes, and seconds. Seconds of time are optional and will be taken as zero if left blank.
Astrology presents some unique challenges for computer arithmetic because of the mixed-base representation used for describing positions in the sky. We need to not only represent a position as accurately as possible within the number of digits we use, but also have rounding boundaries in specific places that have symbolic significance. First of all, times, latitudes, and longitudes are truncated to seconds of time or of arc, with a tiny offset to account for precision loss inherent in the computer's internal 32-bit representation. If you entered them in integer hours or degrees, minutes, and seconds, then the rounded result should be exactly what you entered.
For Zodiac positions, rounding is a configurable option. The default behaviour is that all mixed-base digits of the position except the least-significant will be displayed with the values they would have assuming truncation, and the least-significant will be rounded to nearest even if that gives it an out-of-range value. For instance, a position 29.99999999 degrees after the equinoctial point - almost at the end of Aries - might display as 29° Aries 59' 60"; 29° Aries 60'; or 30° Aries; but never in Taurus. The point of this rounding method is that although it does round to nearest, it will never round in such a way as to change the higher-order mixed-base digits, which have important symbolic value. A position before the sign cusp, in particular, should never be displayed in the wrong sign; and similar protection is enforced at the boundaries of degrees and minutes, to allow unambiguous determination of things like decans. This method has the disadvantage of sometimes producing out-of-range digits, but it seems to me to be the best compromise. It is used in some hardcopy ephemerides.
If you don't like the default rounding mode, you can choose one of the other settings in the options box. "Truncate instead of rounding" will always truncate. This mode is easier to understand; it never produces out-of-range digits; and it means that positions truncated to different boundaries will always agree with each other for as many digits as they have. However, it means that a reported position could be off by as much as one full unit of the smallest digit, instead of one half unit as in the default mode. The example position of 29.99999999 degrees from the equinoctial point might display as 29° Aries 59' 59"; 29° Aries 59'; or 29° Aries.
If you choose the "Clamp rounded values" mode (and not the "Truncate instead of rounding" mode, which takes precedence when both are chosen), then you get the default mode except that any out-of-range values are displayed as being at the end of the range instead of outside it; so anything that would be shown as 60", 60', or 30° will be shown instead as 59", 59', or 29°. This mode seems to combine the disadvantages of the other two, and it is not recommended. In particular, it means that in round-to-minute positions, the last minute of a degree is 90 seconds long while the first of the next is 30 seconds long. (In the default mode, first and last minutes are 30 seconds each, which at least is symmetrical.) But some other software uses the clamped rounding mode, so it is provided for users who might prefer it.
True round-to-whatever, under which 29.99999999 degrees from the equinox would appear as 0° Taurus 0' 0", and several other modes that treat particular digits specially, are offered by the underlying horoscop LaTeX package but not supported by this Web interface.
As of this writing, the currently-downloadable version of the horoscop package does not support advanced rounding yet; it currently does a poorly specified thing almost equal to truncation. The new version, already used in the online service and supporting really correct and configurable rounding support, will be posted for download after I finish documenting it and incorporating a few other requested features. Note that the downloadable version is marked as a beta version, and that's what you get with beta software.
The point and purpose of this service is astrological typesetting, not astrological calculation. It exists to demonstrate the horoscop LaTeX package. The calculations are performed by a separate software module (Swiss Ephemeris) that I did not create; and date and time conversion (from whatever you enter to UTC) are handled by the PHP programming language. My software that I actively maintain and am responsible for is only the part that typesets the chart and the glue logic that combines these and a few other modules into a Web service.
Accordingly, some aspects of the astrological and date-time calculations are not directly under my control. The general policy is that you get whatever comes out of Swiss Ephemeris and PHP; I will attempt to work around any bugs I know about in either package but will not necessarily be responsible for tracking down every last questionable issue. My commitment is that my chart should accurately represent the planets and such as being where my installation of Swiss Ephemeris says they are; whether that's where they really are is an issue to take up with the authors of Swiss Ephemeris.
Whichever dates are covered by BOTH my home computer's installation of Swiss Ephemeris and my hosting provider's installation of PHP. That raises some isses.
Swiss Ephemeris's high-precision ephemeris files for the traditional planets, the Moon, and Astrodienst's idea of the "major" asteroids (Ceres, Pallas, Juno, Vesta, Chiron, and Pholus) are supposed to cover the range 2 January -5400 to 31 December 5399. However, they're not provided in a single package but as separate files for different year ranges, and Astrodienst discourages people from downloading the whole set all at once because of server-load issues. They request that you only take what you really need. As of this writing I have the ones covering the years 0 through 2399. If there are other year ranges you really want, contact me and I'll grab others. I may at times acquire additional data files without promptly updating this FAQ entry, so the real coverage may be greater than what's described here.
Swiss Ephemeris also includes what they call the "Moshier semi-analytic theory" which covers the years -2999 to 3000 for the traditional planets and Moon only. It is less accurate, but should be plenty accurate for astrological purposes (within less than a second of arc except for the Moon and Lunar derived points). If you enter a date that is in this range but not in the range covered by my installation of the high-precision ephemeris files, then this is what you get.
For individual asteroids, I have also installed a bunch of the "short asteroid files" from Astrodienst, which only cover the years 1500 to 2100. On request I may be able to get the "long" versions of some of these files; I'm not sure whether those are on the Astrodienst FTP site or not.
If you request an object for a date on which I have no ephemeris data, it will probably appear on the chart as being at 0° Aries. That's less than ideal, but as the doctor said to the patient, "Don't do that."
Be aware that for some minor planets or asteroids, accurate data may simply not exist for dates too far from the end of the Twentieth Century in either direction. Many of them have orbits extrapolated from just a few observations, the accuracy of which necessarily degrades for dates far from the dates of the observations. Some of them have orbits that interact with those of major planets in a chaotic way. For instance, Chiron had a close encounter with Saturn in the year 720 and it is not possible to compute where Chiron came from prior to that time based on present-day observations.
In light of these issues, to prevent people from confusing themselves there is an "allow dates outside the 20th and 21st Centuries" check box on the Web form. To use such dates, this box must be checked; and if it is, the date you enter will be just passed through to the Swiss Ephemeris interface and it will be assumed you know what you're doing. See also the next two questions and answers.
During testing with a date in the year 1626, a user discovered some bizarre behaviour that seemed to relate to an incorrect conversion between the Julian and Gregorian calendars. On investigation this turned out to be the consequence of a bug in PHP 5.2.1. It seems to be similar to bug #40743, but I am not sure that it is exactly the same bug. I have upgraded to PHP 5.2.6, and this bug seems to have been fixed, but PHP's handling of the Julian and Gregorian calendars remains poorly documented.
The way in which I am using PHP's calendar functions is intended to make it use the Gregorian calendar consistently. However, this may be related to the selected time zone. It is possible that in some time zones, PHP will assume you entered a Julian date for dates before some date which may or may not be 3 September 1752, the traditional assumption of the Unix cal(1) program. It is also possible that PHP may interpret the date in a way that is not correctly the Julian nor Gregorian calendar, because I am not confident that all the bugs in this area were correctly fixed by the PHP team. It appears to me that the chances of correct behaviour are best for dates entered as UTC.
Accordingly: I strongly recommend that for dates prior to the mid-Eighteenth Century, you enter them as Gregorian dates and select the UTC time zone; and cross-check with some other software (the position of the Sun should be a dead give-away) to make sure you're getting the date you intended.
The traditional Gregorian calendar counts "2 BC, 1 BC, AD 1, AD 2..." with no year zero. Nowadays a lot of people substitute "BCE" and "CE" to avoid the affirmation of Christian religious doctrine implicit in using the older abbreviations, but they still count "2 BCE, 1 BCE, 1 CE, 2 CE..." Others, who want arithmetic to work consistently and thus need a zero, count "-1, 0, 1, 2..."
The ISO 8601 standard appears to specify the last of those conventions, with a year 0 equivalent to 1 BCE. PHP claims to follow the ISO standard, and this service uses PHP's date-handling functions; so you should enter dates prior to the year 1 as zero or negative, with 0 = 1 BC = 1 BCE. I cannot promise that it will actually work correctly; see comments above regarding PHP bugs. Swiss Ephemeris also claims to use the year-zero numbering scheme; it is easier to test and does seem to be doing it correctly.
On 1 January, 2001.
This situation occurs for instance with Placidus or Koch houses and locations inside the Arctic or Antarctic Circles. You get whatever comes out of Swiss Ephemeris, without comment or warning. I think Swiss Ephemeris will automatically switch to Porphyry houses in such cases. See its documentation, and/or "don't do that."
Beware of accidentally interchanging the latitude and longitude; I discovered some bugs in the polar-circle handling (now fixed) when I entered Waterloo, Ontario (longitude 80° 31' W) as being at latitude 80° 31' N.
Sometimes people want to post charts on the Web for others to view, for instance in online Web logs, journals, BBS discussions, and so on. The best way to do that is to download the chart and post it in one's own server space. However, many people don't have server space they can conveniently use for this purpose.
If I ever display a chart as an image in an HTML page, then I must make the chart available through some kind of URL, however temporary and obscure, and then it is inevitable that people will embed the URL elsewhere on the Web, hoping to get the benefits of image hosting while using my bandwidth and server space instead of their own. This practice is variously known as "hot-linking," "embedding," or "bandwidth theft."
There are two ways I can go on that. I can attempt to prevent you from doing it, or I can accept that you will attempt to do it no matter what I say, and then work out a way to turn it to my advantage. Other services, like astro.com's, try to prevent hot-linking by expiring the images really fast, and/or blocking access based on Referer: [sic] headers, so that if you try to embed their images, it won't work. I've chosen to take the other path and make hot-linking be okay.
So here's the deal. If you want to hot-link a PNG chart from this service as an embedded image somewhere, fine, go ahead and do it. You'll need to generate the chart with the "PNG - hosted" output option so that it gets a URL in the first place. Then you can use the embedding code on the resulting page to post it wherever. I've included both HTML and BBcode versions. But when you post it, please post it with a link back to my site. If you use the provided embedding code, the link will be included automatically. Then when people click the link, I get the chance to show them some of my content, promote my own projects, sell ad impressions, and so on. These clicks compensate me for the small but nonzero amount of money it costs to serve your embedded image.
As an incentive to encourage you to really post the link properly, and also to prevent unused images from cluttering up my server, the image expiry is tied to the incoming clicks. Charts will be kept until seven days after the last click. So you can keep a chart on your page indefinitely as long as people click on it at least once a week, but if a chart isn't being used and clicked on, it will eventually go away. It is important that you use the exact URL provided in the embedding code, because it contains the ID of the chart whose expiry date should be adjusted; if you use some other URL to link to my site, that's nice, but it won't help your chart stay online.
I reserve the right to point the incoming-click URL to whatever I want to advertise, filter it to block cheaters, change the timeout settings if I run out of server resources, and so on.
You can enter your name and birth data on the form, and if you do, that is obviously information you might want to keep secret. The system makes some effort to protect it. In particular, because this is a POST form, assuming your Web browser obeys the standards, the data won't go into the server logs. However, it does get written to disk as part of the normal process of generating the chart. Normally each new chart overwrites the old data; but the last chart generated at any given moment does remain on my disk until it's overwritten, and when there is an error I will examine that data for debugging purposes. Note, also, that the data crosses the unencrypted Net on its way between your browser and the Web server and between the Web server and the backend server.
If you choose the "PNG - hosted" output format, then the resulting chart will be stored on the Web server and shown, including the personal information included in the chart, to anyone who views it with the associated URL. These URLs are randomly generated and difficult to guess. It is extremely improbable that anyone could view one of these charts unless you give them the URL, directly or indirectly. Nonetheless, such charts should be considered public knowledge. The purpose of the "PNG - hosted" option is to make it easy for you to publish charts to the world; do not choose it for any chart you wish to keep private.
I believe that the privacy of data on this system is at least as good as on any comparable free astrological chart service. If you want tighter security, I suggest downloading an astrological software package (mine or any other) and running it locally on your own computer.
In that case, astrological information on this site is provided to you for entertainment purposes only.
This most likely means that you didn't fill in some necessary piece of information on the form, such as the date and time.
This probably means that you entered some punctuation in the name that the system considers invalid for names, such as a backslash.
Error 500 usually happens when the Web server can't connect to the backend server (my home computer) to compute the actual chart. Because the software used to make the charts won't run on my hosting account, the page you connect to on the Web host is just a sort of gateway that passes your information back to my home computer. If the connection between the two breaks, as it sometimes does, then you get error 500. It is also possible for other problems inside the system to cause this error. Unfortunately, there is not much you can do about error 500 except wait and try again later. If it persists more than a day or so, email me to complain.
That may mean the connection to the backend broke (like error 500 above) or it might conceivably mean that the service is so heavily loaded by other people using it, that it can't handle all incoming requests. Overload is unlikely, but if the service becomes extremely popular it could be a possibility. Timeouts could also be caused by general Internet connection problems on your end.
Error 503 normally indicates that you have exceeded the limit for how often the service will generate charts. You're limited to a long-term average of one chart per four hours (six charts per day), although you can exceed this limit for short periods. If you get this error, try waiting at least four hours and then trying again.
In more detail: the system uses what is called a "token bucket" rate limiter. Every unique IP has a store of tokens. You start with 50 tokens. Every time you successfully generate a chart you use up one token. If you have no tokens remaining, you get error 503 instead of a chart. Every four hours you get a new token, unless you already have 50 in which case you just stay at 50. So you can make charts in bursts of up to 50 at a time, but the long-term average is limited to one per four hours.
The reason for the limit is to prevent the system from putting an undue load on my server resources, bearing in mind that I have to pay for my hosting and I don't get paid to operate the service. The ad boxes on my site currently bring in about $0.20 per day for the whole site - nowhere near enough to cover hosting expenses, and almost none of that is directly attributable to the chart service. I figure that anyone who needs more than six charts per day over the long term is probably either a professional, in which case they shouldn't be exploiting a free service, or else a serious amateur who could download the software and compute their own charts themselves.
Nonetheless, if you think you have a good reason to use my service beyond the limit, or if you want to pay me to help you build a service of your own, please email me.