W3C schema for the RFC 1123 date format

Here's a quickie I didn't find anywhere: XSD for the RFC 1123 date format, as used in http headers; note its only for GMT and years 2000 -2099 (my particular case):

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation><xs:documentation>Schema for RFC 1123 date format type</xs:documentation></xs:annotation>

<xs:simpleType name="RFC1123_date">
<xs:annotation><xs:documentation>RFC 1123 date format.</xs:documentation></xs:annotation>

<xs:restriction base="xs:string">
<xs:pattern value="(Mon|Tue|Wed|Thu|Fri|Sat|Sun), [0-3][0-9] (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) 20[0-9][0-9] [0-2][0-9]:[0-5][0-9]:[0-5][0-9] GMT">
</xs:restriction>
</xs:simpleType>
</xs:schema>

Safari 4: Does Acid pass the Acid test?

OK, so I updated to Safari 4 and yes, sure enough it passes the Acid3 test with flying colours. Must be good, then. So I tested it against my two outstanding bugs which I stumbled across:
Corrupt screen memory: Go to that link after visting another page and you'll see the new page just billboarded on top of the one you were looking at.



Try resizing the window to see ugly stuttering visual history as the window moves...



...and then there's simple (but big number) arithmetic inside XSLT. Safari just gets it wrong. Come on guys, where are those 64 bits you promised us? Heres an example of hex conversion, where the large integer here simply gets converted to zero inside safari, but the correct answer is given in Firefox.

So Acid 3 is all very well at testing the fancy new features, but I would have thought that CSS styling of Plain Old Xml would be even more fundamental than testing the new selectors.. so Acid 3 is failing my acid test, at least.