Re: [whatwg] 'datetime-local' and 'datetime' comments

     Hi,

In my opinion, it's normal that datetime and datetime-local have 
timezone and date/time don't. A date is timezone independant and time is 
more a duration then a time relative to a particular instant of a 
particular day.

So making datetime having the behavior of datetime-local does not seem 
to be necessary for consistency. In any case, i think that we still need 
a way to define a datetime in a particular timezone since you cited one 
case in which it make sense.

Another problem is the ouput value that seems inconsistent between 
datetime, datetime himself and datetime-local. By example in the Google 
Chrome/Firefox console :
var f=document.createElement('input');
f.setAttribute('type','datetime');
f.value='2012-01-26 13:37:01';
console.log(f.value); // outputs 2012-01-26 13:37:01
f.value='2012-01-26T13:37:01Z';
console.log(f.value); // outputs 2012-01-26T13:37:01Z
f.setAttribute('type','datetime-local');
console.log(f.value); // outputs 2012-01-26T13:37:01Z
f.value='2012-01-26 13:37:01';
console.log(f.value); // outputs 2012-01-26 13:37:01

I think that whatever you decide for datetimes, it should always return 
a UTC value with only one format (yyyy-mm-dd hh:mm:ss or 
yyyy-mm-dd-Thh:mm:ssZ) to allow us to threat it the same way  whether it 
is relative to the user timezone or not.

On 12/11/2012 18:00, Mounir Lamouri wrote:
> Hi,
>
> We've been working on implementing date and time input types attributes
> at Mozilla this summer and we found out that 'datetime-local' and
> 'datetime' have a quite odd behaviour.
>
> 'date' and 'time' are both timezone agnostic types: you just set a time
> and date and we assume that it is relative to something. So, it seems
> somewhat natural to assume that 'datetime' would be simply those types
> added to each other. Instead of that, 'datetime' has a notion of
> timezone and 'datetime-local' is the timezone agnostic type.
>
> In addition of being more intuitive, it seems that a huge majority of
> date/time usage are timezone agnostics because, usually, the timezone is
> implicit. For example, booking flight/train tickets.
> There is however some use cases I can think of, like scheduling a
> meeting, where, sometimes, you might want to mess with timezones. But
> those are quite rare.
>
> Furthermore, there are currently two implementations for 'datetime' and
> 'datetime-local' I can think of:
> - Opera: 'datetime' is like 'datetime-local' except that there is a
> greyed 'UTC' text next to the datetime picker;
> - Chrome Android: 'datetime' is exactly like 'datetime-local'.
> I haven't checked what is actually sent when the form is submitted by
> those implementations.
>
> Last but not least, I have never seen any [good and simple] UI allowing
> me to pick a date and time in a specific time zone. As far as I know,
> there are no native UI for those things even on mobile where there are
> UI for date and time pickers.
>
> As a conclusion, given the lack of good UI and good implementations, I
> think we should change the behaviour of 'datetime' to match the
> behaviour of 'datetime-local' so developers don't use the former and
> falsely expect the behaviour of the later.
> Also, I would suggest that we remove 'datetime-local' from the
> specifications. If later if find out that we really need a date-time
> picker that is not timezone agnostic, we could add something. For the
> moment, given the state of the implementations and the very tiny use
> cases that could solve, I think having this type would hurt more than help.
>
> Thanks,
> --
> Mounir
>
>

Received on Tuesday, 13 November 2012 10:51:38 UTC