- From: Christian Schmidt <whatwg.org@chsc.dk>
- Date: Wed, 30 Jun 2004 21:42:04 +0200
Jim Ley wrote: > With UTC we have the server relying on something it cannot know - the > accuracy of the users clock and settings I don't know if this has been mentioned before, but it is possible to detect most inaccuracies with a combination of client and server side code. The UA could somehow retrieve the current time from the server, e.g. by looking on HTTP headers (on something that is known not to be cached) or calling a CGI script that returns the current time in a Javascript include or similar. If the current time of the UA differs more than just a few minutes, the user should be alerted. This ensures that the local time is almost accurate, but it does not verify the timezone setting. This can probably not be fixed in a fool-proof way without installing GPS equipment in the user's computer, but some steps can be taken to help the user discover this problem. First of all, I don't think it is very common that the clock is accurate but the timezone is wrong, because in that case any clocks shown on the user's computer would not show the local time, and most user's would probably fix that. On computers or other clients without a visible clock, it may be helpful to display "the current time is 10:30 GMT (Daylight Saving Time)" in the <input type="datetime"> control. In all cases it might be helpful, if the datetime control showed the current timezone and also allowed the user to select another timezone from the list. This would be useful when specifying times that should be used in other timezones like times for teleconferences or arrival times for flights, and in all cases it will help users understand the concept of universal time. These suggestions may not catch all problems, but they certainly will eliminate a lot. Christian
Received on Wednesday, 30 June 2004 12:42:04 UTC