- From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Date: Sun, 13 Jan 2013 16:00:32 +0100
- To: whatwg@lists.whatwg.org
On 13.1.2013 14:52, TAMURA, Kent wrote:
>
> On Tue, Jan 8, 2013 at 9:47 AM, Ian Hickson <ian@hixie.ch> wrote:
>
>> > However, I'm not sure how this can be presented to the user. In the
>> > example above I suggested that time input UI should be accompanied
>> with
>> > local time zone ("Europe/Helsinki" in my example). However, that would
>> > suggest that this info would be transferred to the server and that the
>> > server is expected to follow political time zone changes to that
>> > timezone. The user could be assuming that he has defined a specific
>> time
>> > in a specific timezone (an absolute time as far has he knows).
>> >
>> > In the reality, the server would like to transfer *the responsibility*
>> > for the possible future time zone changes to the user -- the server
>> > expects user to come by and modify the absolute time in case the user
>> > local timezone has been modified since entering this absolute time. I
>> > have absolutely no idea how on earth this could be explained to casual
>> > user. And even if it could be explained, I'm pretty sure the end user
>> > wouldn't be happy with that responsibility.
>
>> Yeah. Indeed.
>
>
>> > The next best choice would be to have datetime-with-timezone but
>> > unfortunately
>> >
>> > (1) Official database for all timezones does not exist
>> > (2) Official timezone names (or labels) do not exist
>> > (3) Timezones are subject to future political decisions
>> >
>> > The problems (1) and (2) make transferring the timezone information
>> from
>> > the end user to the server very problematic and the problem (3) makes
>> > any work to fix (1) and (2) a bit pointless. This is because even
>> if UA
>> > could successfully inform the server about the correct timezone, the
>> > server could be using a week old timezone data that is not up to the
>> > latest political events. Or the server might be using latest timezone
>> > data but the UA could be using three year old data. In either case,
>> the
>> > absolute time in UTC could be different for the server and UA.
>
>> Indeed.
>
> So, I think it's impossible for us to build reasonable UI for
> type=datetime. It should be removed from the specification.
>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
datetime-local shoud be removed from specification and datetime should
reflect user's settings (e.g. underlying OS)
BK
Received on Sunday, 13 January 2013 15:01:18 UTC