[whatwg] Re: input element types

Ian Hickson ian at hixie.ch
Wed Jun 23 09:25:59 PDT 2004

On Thu, 17 Jun 2004, Jim Ley wrote:
>> In what possible situations would a UA not have access to the user's
>> UTC offset?
> When their in a different timezone to the UA.  (remember it's _users_
> who will be entering data in the form, not their UA's)

A misconfigured UA is always a possibility, but given the problems that
would already be present with the UA (and indeed the entire platform) if
the time zone was incorrect, I fail to see how that is a particular
concern for Web Forms 2.

> In anyway, remember it's not just the timezone that they need, but also
> the summertime behaviour and the timezone of the location the user is
> being prompted about.

Support for this is already required by ECMA262.

> Going back to the flight booking example, look at all the pages on the
> web, and their all about local pages.

Not sure what you meant by that.

> The next problem is of course that this is meant to be a backwards
> compatible specification that still works on legacy clients, without
> script etc. there's no way we can do it.

While certainly not as pleasant as a nice UI with a pretty clock, it is
still possible for users to enter the datetime format if their UA doesn't
support it and does not have JavaScript enable for the page to help them.
So it is backwards compatible, just not very pretty.

I don't really see a better way to do it, although I'm open to

(I don't think extending the definition to allow any timezone is a good
idea, given that this would increase the implementation burden on
server-side implementors to a point where they are highly likely to make

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list