2013-01-16 4:20, Ian Hickson wrote:
* If the type=datetime UI asks a local datetime, UA needs to convert local datetime to UTC datetime, of course. However, it's very hard to implement. ** The UI needs extra work for edge cases of daylight saving time - standard time switching. ** A local computer doesn't have complete information of daylight saving time period of every year.Yes, it's hard to implement. But someone has to do it. I'd rather it was you and a handful of other browser vendors than a million Web authors.
I don't think a million authors do such things. Instead, a few people may develop libraries for the purpose.
The harder something is to do, the more valuable it is for browser vendors to be the ones to do it rather than the site authors.
Since the use cases are rare, is it better to force browser vendors to develop code to implement it, in their own ways, than to let various software developers set up libraries for it? Since the browser implementations would, with practical certainty, lack adequate localizability (according to page language) and customizability, the HTML construct would not be used much.
Authors, or their employers and clients, don't want just "a date and time picker" for example. They want a picker that suits their overall design. I don't think this will change anytime soon. Pages now use a wide variety of date pickers. While <input type=date> might be useful for testing and quick prototyping, and might be used by functionality-oriented authors who don't care much about look and feel, <input type=datetime> would rarely be used even for such purposes, so it would be an undue burden on browsers
Yucca
