[whatwg] <output> and onforminput

On Fri, 25 Jun 2004 23:18:20 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> > Drop the UTC requirement, and I'd be completely happy with understanding
> > datetime, but I just don't get it at all with this requirement, which is
> > why I'm still asking for the usecase!
> 
> I really don?t understand what you think the "UTC requirement" is. Do you
> mean drop the timezone specifier altogether? Or drop the requirement that
> the timezone specifier be UTC?

Yep, it's not used now, the timezone is always known through context,
since for legacy clients it will still need to be known through
context, there's no point having this extra specification.  Especially
since users often have their timezone wrong (Windows timezone
implementation is very poor, so many developers I know keep it on UTC,
My copy of Opera on Symbian 60 or the OS itself doesn't have anywhere
to tell the timezone, unless I've just not found it.)  It's just going
to be unreliable, and unreliability does not help anyone.

> so why not simplify the life of the WF2-only
> server author and convert the time to a predictable timezone all the time?

Because it's less reliable than the alternative, and doesn't require
any special behaviour or a correct clock on the client.  It doesn't
matter that my machine thinks it's December 2007, and the timezone is
Nepalese, if I fill in a form setting a date for 30th June 2004 at
3:30 that's correct - all of a sudden it wouldn't be correct under WF2
as it would compensate for my timezone and clock.

With UTC we have the server relying on something it cannot know - the
accuracy of the users clock and settings - look at usenet and mailing
lists for examples of how accurate these are in the real world.  I
simply don't think there's enough of a use case to deal with this
constraint, when in almost all use cases I know of, the context is
known.  Even your multinational example above generally uses more
complex controls than just a datetime - that let the user pick from
times that specifically list the times in various timezones because
users are generally not quick to make the combinations.

Jim.

Received on Friday, 25 June 2004 16:36:15 UTC