[whatwg] <output> and onforminput

Jim Ley wrote:
> So you break all caching, you ensure that WF2 forms have to be
> submitted in the same "session" as they are downloaded (I can't
> download a form last week, and submit it today, as my clock's likely
> to have changed)  and you can't deliver forms by email, from CD etc.
> for submission to the web.
It wasn't meant as a requirement, but as a suggestion to how UA's could 
help users detect inaccurate clocks. The UA may choose not to use it at 
all or only when it has reason to believe that the users clock is 
inaccurate.

If the user has recently verified that current setting, or if the OS has 
recently synchronized the clock with an NTP server, the detection could 
omitted.

It also wasn't meant as a silver bullet to solve all inaccurate clock 
problems one could imagine, but I think that it would be helpful in most 
common scenarios.


> It certainly seems an awful lot of work when I failed to see anyone
> have a problem with this on the web today.
Even if a website doesn't allow the user to enter datetimes, it would 
often be appropriate to display times in the user's local timezone (e.g. 
on a news site). The user would either have to specify the timezone 
somewhere in the web application, or the timezone should be read from 
the UA using Javascript. In either case the application should take 
measures to ensure that this setting is correct - so the work should be 
done anyway.

The problem does exist on the web today. If your clock is properly 
configured, you probably wont notice it, though. Slashdot allows you to 
specify your timezone. I don't think eBay does - that's confusing, 
because absolute time is relevant with respect to when an auction ends.

Clock inaccuracies is not a problem specific to Web Forms, but a general 
problem for many webpages. I don't know if that makes it outside the 
scope of the Web Forms specification to help solve this problem.


Christian

Received on Thursday, 1 July 2004 03:07:00 UTC