[whatwg] Re: input element types

[Ian Hickson]

On Thu, 24 Jun 2004, Jim Ley wrote:
>>
>> 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?

E-mails sent at the wrong time. Alarms going off at the wrong time.
Backups launching at the wrong time.


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

So? How does that translate into a problem for WF2's datetime?


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

Which OS?


>>> 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" ?

Sucre. Section 15.9.1.7 of ECMA-262 Edition 3 Final.


> Also the summertime behaviour for different locations than the current
> one, which is another requirement for useful use of the datetime
> control.

That is part of knowing what timezone you are in, and in practice is
dealt with by the OS. The UA simply queries the OS.


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

That site doesn't use an equivalent of the datetime control. It has the
equivalent of a date control followed by a <select> with some times and
some vaguer times.

Here is a snippet of what a page for a multinational company's intranet
site might look like if it used WF2:

   <form action="new-event" method="post">
    <ul>
     <li> <label> Event title: <input type="text" name="name"> </label>
     <li> <label> Start time: <input type="datetime" name="t_start"> </label>
     <li> <label> Edit time: <input type="datetime" name="t_end"> </label>
     <li> <input type="submit" value="Continue...">
    </ul>
   </form>


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

Yeah, it's a fair point. Users could, in legacy UAs, use any time zone
specifier (or none, maybe, with the server making an educated guess) that
they wanted. WF2 UAs would always be able to give a time zone though (and
can thus always convert it to UTC) since the user would provide the time
using his local timezone.

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