One subtle new feature is the ability to rotate the clock. As of revision 3.0.8, drag anywhere, and the clock rotates accordingly, while continuing to update the time as usual. Click anywhere to restore the clock to its normal, upright position. If this feature has any actual utility, it is the ability to view the lunar illumination indicators in their correct orientations.
Unfortunately, even rotated to the proper vertical orientation, the lunar disks will not necessarily represent the orientation you'd see if you went outside and looked at the moon. The problem is the inability to calculate the parallactic angle, which depends on one unavailable piece of information: the viewer's latitude. Otherwise, the disk illuminations shown are quite accurate, based, as they are, on gratuitously precise calculation of the positions of the Sun, Earth and Moon. Basically, every time Meuus said "if no high accuracy is required, do it this way" I did it the other way. I think a clock should have precise and beautiful innards. And because this one is virtual, all of the gratuitous levers, springs and gears add nothing to the cost, and therefore neither economics, nor common sense, need be allowed to spoil the clock maker's fun.
On the off chance that anyone else has a use for all of those extra mechanics, I'm releasing the clock under the GNU General Public license, version 3 or later. (I've also written a much cleaner Java implementation, complete with unit tests, if anyone has a use for that.)
As always, the clock is best appreciated by opening it in a separate window, and making that window as large as possible.
- Fixed in clock version 3.0.11: The hour-of-day indicator now adjusts to the change from daylight savings time to normal time.
- Firefox 3.0.1 renders neither the text on the clock face, nor the time indicators. There were no such problems in the earlier versions of Firefox 3, though I don't know at which build the problem was introduced.
Dateobject (year, month, day, hour, etc.), it is important to use those methods in order from least significant (milliseconds) to most significant (full year). Otherwise, the date may be corrupted.
- No version of Firefox or Safari respects the
zoomAndPanattribute of the
svgelement. According to section 16.7 of the SVG 1.1 specification, when the
zoomAndPanattribute is set to
magnify, “the user agent shall provide controls to allow the user to perform a "magnify" operation on the document fragment.” Sadly, that doesn't happen at present.
- Safari 3.1.1 refused to execute the script in the clock when I initially embedded it in this post. After some experimentation, the problem was resolved by including the UTF-8 Byte-Order-Mark (BOM) at the start of the clock's source file. Firefox 184.108.40.206 had no problem with the absence of the BOM, and Safari shouldn't have had a problem, either, as the XML specification is very clear about how to identify the character set of an XML file with, or without, a BOM. If I can implement that algorithm (and I have, in Qwicap), gosh darn it, so can Apple. (But perhaps Safari does implement it, and the addition of the BOM merely correlated with, rather than caused, the resolution to this problem. Right now, I don't care enough to perform all of the tests required to find out.)
- Neither Firefox 3.0b5, nor 220.127.116.11, can cope with a negative X radius for the ellipse that defines an arc drawn by the "arc" command of the
pathelement. Safari 3.1.1 handles this without any problem. Fortunately, it is possible to workaround the Firefox bug(s) by using the absolute value of the X radius in the arc definition, and then changing the arc's "large arc" flag to zero when the radius goes negative.
- Firefox 18.104.22.168 runs this clock very slowly. One might suspect that all of the additional astronomical computation associated with the lunar illumination indicators is responsible, but, in fact, that code runs only once when the clock begins running and then once more each time the month changes. My best guess is that the Firefox 2 SVG engine is of generally low performance (I believe that's widely acknowledged), and that it probably redraws more of the image than is strictly necessary whenever the image changes (for example, when the second hand moves). Those two factors combine with the increased graphic complexity of the new version of the clock to consume a startling amount of CPU time, sometimes so much that it takes much more than a second to redraw the clock after each "tick" of the second hand. While that looks awful, the clock still keeps perfectly good time; it just can't display it smoothly.
- Firefox 3.0b5 has a dramatically faster SVG engine than its predecessor, and therefore has no trouble keeping the second hand moving steadily, while using very little CPU.
- The SVG engine in Firefox 3.0b5 has bugs that the engine in 22.214.171.124 does not. The failure to draw the names of the months in the clock is one such bug. (Strangely, the names put in a partial appearance when the clock is rotated.)
- For the moment, the hands-down winner for SVG performance and correctness is Apple's Safari, version 3.1.1. Resize the clock to fill your screen and it'll not only draw correctly, but it will barely touch your CPU while doing so. Hopefully, the problems in Firefox 3's SVG engine will be resolved soon, and we'll have two cross-platform browsers with high-performance SVG engines in them. (Perhaps there already are two, or more, such browsers - I haven't investigated Opera, for instance.)
GregorianCalendarclasses (a need they seem to acknowledge in their forums), I'll have to give it another try.