Further Horological Tinkering

My previous SVG clock experiment merely demonstrated that Scalable Vector Graphics (SVG) could do some basic work in modern browsers like Firefox and Safari, but it didn't give SVG much of a workout, and its clock design had nothing new to say about time. In contrast, here's a new clock that exercises more of SVG's functionality and that says a lot more about time and our passage through it by displaying our position in the year, the month, the week, and the full day.

Potentially subtle points: The dark tick marks in the year ring denote the first day of each of month, while the normal tick marks indicate all of the other days. (Since 2008 is a leap year, there are currently 366 total tick marks in the year ring.) With the exception of the first one, the dark ticks in the month ring denote the start of weeks. (Note that, contrary to popular opinion, the week begins on Sunday in the Gregorian calendar, not on Monday.) Also, the text in this clock wants to be drawn using the Copperplate font, so if the text looks bad, it may be because your system lacks that font. (Of course, it could also be because you detest my choice of typeface.) Finally, it almost goes without saying that this clock contains detail that is barely visible when seen at the size show below. To get the full effect, open it in a new window, and make that window nice and big. Because it's SVG, it'll scale to any size.

Browser-specific oddities (for Safari 3.1.1 and Firefox 2.0.0.14) and implementation notes:

• The SVG implementation in Safari is much faster than the one in Firefox.
• The SVG implementation in Safari includes a bug that can prevent a portion of the area of the image affected by a change from being redrawn. In this clock, the second hand leaves behind artifacts as it approaches the fifteen second-markers.
• Firefox treats font names as case-sensitive, but Safari does not.
• When defining paths on which text will be drawn, Firefox insists that those path elements be children of a def element (or perhaps it's happy as long as something prevents the paths from being rendered). Safari doesn't care.
• Firefox's SVG parser doesn't care if some attribute values violate their syntax. For example, transform='rotate(60 400 400' is perfectly acceptable to Firefox, even though the closing parenthesis is missing from the end of that rotate command. Safari won't tolerate that mistake.
• Firefox will expend considerable resources redrawing elements that have moved so slightly that no change of any kind is visible at the rendered resolution. (Either Safari is smarter than that, or its faster SVG renderer hides the issue.) Firefox's SVG renderer can be placated to some extent if your code limits the precision of the positions, rotations, etc. that it calculates (limited, for example, to two decimal places), and only tells the SVG elements to change their position when their new positions differs from the previous positions.
• Safari's SVG rendering fails abysmally if you change the size of the text on this page.
• Firefox 3.0b5 can handle this clock when it is read from a file, but not as it exists, embedded in this page.
• Javascript bas no built-in means of providing some basic date information like the internationalized name of each day of the week (even though it appears to know them), so the English names are hard-coded into this clock. The more I work with Javascript, the more I like Java.