Daylight uses two new filetypes, location which holds latitude, longitude and placename and filetype event which holds a particular date in addition. Double clicking on one of these file icons will start the application with that file already loaded, calculated and displayed in two seconds or less. Alternatively start the application by double clicking on the !Daylight icon and a location file named default held in the application directory will be loaded and calculated for today's date. The default file can easily be altered by the user to hold his or her home town or location of choice. These filetypes are not registered with Acorn so conflict is possible. Once the application is running, fresh locations or events may be loaded either by double clicking on their icons or by dragging the icons to the main window, all precisely according to the Acorn guidelines.
The latitude and longitude are displayed in writable icons and may be changed at will. The time displayed initially is zone time which does not take account of summer time or other national ideosyncrasies. The zone time is shown in a writable icon and the event times displayed are modified whenever this icon is changed. By setting this icon to longitude divided by 15 local mean time is displayed. Click on the word zone and it will change to local. The time then shown is the local apparent time based on the sun being on the local meridian at 12h00. This is the most appropriate time to use in a historical context since mean time has only come into common use in the last hundred years with the general availability of accurate clocks. Zone time has only appeared since the introduction of radio time signals. The time displayed can be changed to Universal Time by clicking on the word local. In all cases the events displayed are for the date at the location of interest.
Play with the arrows under the date for a few minutes and discover that the date may be changed by the day, month, year or century. The date displayed changes from the Julian to the Gregorian calendar in 1582. Thursday, October 4th, was followed by Friday October 15th. This is a function of the library procedures and since it was by Papal decree I have not had the temerity to change it although the Gregorian calendar was not adopted in protestant Britain until 1752. In consequence dates given between 1582 and 1752 in British history books may have to be converted from the Julian or old style calendar to the Gregorian or new style calendar. Add ten days between 5th, Oct.1582 and 29,Feb 1700. Add eleven days between 1st, Mar.1700 and September 1752. The retrospective dates on the Julian Calendar are not taken back before Saturday,1st. January in Anno Domini 1. There seems to be no firm agreement on whether a year 0 should be included or not. It is all hypothetical in either case. Any historian seeking accuracy to a particular day before this date would be well advised to work directly to the scale of Julian days.
The menu leads to saveboxes for event files, location files or textfiles. If a textfile is dragged to !Edit or !Impression the file is transferred without being written to disc first. I have seen frequent mention of this multitasking facility but have yet to see another application written in Basic that does this.
I undertook this project as an exercise in programming the graphic interface. The hands-on experience has been invaluable. I did not expect to have to rewrite astronomy routines. The original routines of Dr.P.J. Duffet-Smith are excellent. For any time given as a Julian day and fraction thereof they evaluate the ecliptic longitude from a polynomial and then transform it to Right Ascension and Declination, allowing for parallax. These routines found their way to the Archimedes through D. Fangandini and Ivor Clarke who converted them to BBC.Basic style procedures but still left all the GOTOs in place. The GOTOs are now replaced by structured control statements so the procedures may be used as a separate library and the logic is easier to follow. The sunrise problem is one of those calculations where the numbers required to give a solution depend upon the solution. This is more evident in the case of the moon than of the sun. Moonrise which can occur at any time of day is a function of Right Ascension which changes at a mean rate of 51 minutes per day. To calculate the Right Ascension you need to know the time of moonrise and you cannot calculate the time of moonrise without the Right Ascension. The computer is suited to using the iterative method in solving these problems. The more iterations used, the longer the solution takes. Even the Archimedes takes a moment to work through the many polynomials describing the moon's complex motions. In rewriting the procedure that calculates moonrise and moonset I have reduced the number of times that the Right Ascension of the moon is evaluated from seven to four without degrading the accuracy of the final result. There were other reasons for rewriting the rising and setting procedures. The old routines kept on stepping into the wrong day particularly when calculating events away from the meridian of Greenwich.
The time of sunset is calculated for the instant when the centre of the sun is at an altitude of 0 degrees relative to the horizontal plane of the observer. The sun is then described as having a zenith distance (the angle from the observer's vertical) of 90 degrees. Owing to the dip of the observer's horizon below the horizontal and the effect of atmospheric refraction, neither of which is a constant, it is generally accepted that the moment of sunset is that when the lower limb of the sun touches the visible horizon. It is therefore not practical to display sunset times to the nearest second although the original routines did this. A new procedure added to the library calculates the times of the beginning and end of civil twilight. These are the limiting moments when the horizon is clearly visible at sea or a grey goose can be seen at a mile on land. The corresponding zenith distance is 96 degrees.
