The most interesting thing is that the server returns the exact date/time in the HTTP header.
“Date: Wed, 12 Aug 2009 07:01:36 GMT”
What I'm thinking is that you'd just need to parse the header and adjust for (local time +- hours from GMT, or hit a local server) and you've got a RTC...
Would anyone have code I could re use/task to parse out the individual fields?.
It's not a very accurate RTC considering you're not taking into account:
Line latency
Retransmissions (that add to the overall delay)
The time it takes to process the packet by the shield and parse the HTML data
Daylight savings, does the remote server use it?
I am not sure you can overcome some of these short comings, but perhaps taking a peek at this project will help: HTTP Time Protocol. Maybe they have found clever ways to deal with some or all of the above.
Granted it's not going to of use in sub second (or probably even second) timers. but where you want to say collect samples over a long period it should be perfect. or where you want to display the time in a project it would also be good.
I did look at HTTP time but not all NTP servers support it.
Personaly if my clock is only out by a sec (or two) i'm not too worried
You could also use this to sync with the software RTC in the playground.
Syncing wiht the web server say every few hours would get you quite an accuarte timer. Especialy over long periods. eg: would be accurate to within a sec or two over as long as you had internet access.
This approach is quite popular on some computers that does not have centralized NTP server and have limited internet access (using proxy, for example). It is called HTP: http://netsecure.alcpress.com/htp/ of course it's not as accurate as NTP.
To minimize latency, you can try to get time not from google.com, but from a page of your internet provider, the time probably would be as accurate, but network latency should be much smaller than from trying to contact google.