[whatwg] Re: input element types

On Wed, 23 Jun 2004 16:25:59 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> 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.

What problems exactly happen when the timezone isn't configured
correctly? I know lots of people who don't change timezone's when they
change countries - I just spent 5 days in .no, didn't change my
laptops timezone.  I've not even found where on my Opera browser or
the OS it runs on to say which timezone I'm in, perhaps you could
check with the browser team and they could tell me?  As you're so
confident this is not a problem.

> > 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.

Could you highlight which parts of ECMA262 state that the UA needs to
know the "timezone of the location the user is being prompted about" ?
 Also the summertime behaviour for different locations than the
current one, which is another requirement for useful use of the
datetime control.

> 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.

Could you provide an example page using the datetime control Perhaps a
copy of http://timetables.oag.com/man2/ in WF2, and how that will
work.

> (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
> mistakes.)

Server side implementors already deal with all of this regularly, and
comfortably, I don't see why anyone is going to disadvantage their
users when they can already use well understood UI's that can do it,
without any significant server burden.

Jim.

Received on Thursday, 24 June 2004 05:49:00 UTC