W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2004

"datetime" (Was: [whatwg] <output> and onforminput)

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 26 Jun 2004 00:14:52 +0000 (UTC)
Message-ID: <Pine.LNX.4.58.0406252358170.14689@dhalsim.dreamhost.com>
On Sat, 26 Jun 2004, Jim Ley 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

Yep which? I gave two mutually exclusive options.


> it's not used now, the timezone is always known through context

Which is a bug. The fact that Web applications now guess the timezone in
contexts like these is not a feature.


> for legacy clients it will still need to be known through context,
> there's no point having this extra specification.

Just because legacy UAs require that servers guess what " 100." means as
the input from a numeric field doesn't mean there is no value in having an
explicit numeric field. Same here.


> Especially since users often have their timezone wrong (Windows timezone
> implementation is very poor, so many developers I know keep it on UTC,

So because a small fraction of users may have incorrect settings, we
should require that all users suffer the risks of the server guessing the
timezone? Please.


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

Series 60 devices automatically set the timezone from the network
provider, so it is always correct.


> It's just going to be unreliable, and unreliability does not help
> anyone.

It is certainly not going to be more unreliable than having servers guess
at the timezone.


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

If you set a date for "30th June 2004 at 3:30", the server has absolutely
no way to know which of around 36 hours you might actually mean.

This is not more reliable than having that time be converted to the real
time in a format the server can immediately fully interpret.

Optimising WF2 for users whose computer clocks are that far wrong is
simply not sensible, especially as technologies like NTP become more
widely used.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 25 June 2004 17:14:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:34 UTC