Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

HTML5, input type datetime vs datetime-local, which should I use?

Tags:

html

I can't find more difference like on returned value...

"2011-10-18T00:00:00.00Z" // datetime value 

"2011-10-18T00:00:00.00" // datetime-local value

Am I missing something?

like image 978
AgelessEssence Avatar asked Oct 19 '11 00:10

AgelessEssence


People also ask

What is input type datetime-local?

The input element with a type attribute whose value is " datetime-local " represents a control for setting the element's value to a string representing a local date and time (with no timezone information).

Is datetime valid in HTML5 forms?

The date and time input types produce controls for entering dates and time in the correct format, including providing native date pickers in some browsers. Date related types include: type=date (yyyy-mm-dd) Year, month, and day, with no time.

Which HTML5 input type allows users to select a date and time with time zone?

Datetime input type allows the user to select date and time along with time zone but it does not support Internet Explorer, Firefox, Chrome or Opera browsers.

Is datetime part of input type attribute in HTML5?

HTML5 has the following new input types: color, date, datetime, datetime-local, month, week, time, email, number, range, search, tel, and url.


1 Answers

Update: W3C added type@datetime-local back and dropped support for type@datetime - browsers now render datetime as normal type text: see Why is HTML5 input type datetime removed from browsers already supporting it?

Old answer for reference

I hope you did not chose datetime-local. :-)

W3C HTML has dropped input type@datetime-local; "little independent value & source of potential developer confusion"

Source: https://twitter.com/html5/status/433038890937901056

History of the process is here: http://encosia.com/setting-the-value-of-a-datetime-local-input-with-javascript/

There’s been some confusing instability around datetime inputs as HTML5 has coalesced into a recommendation.

Early on, the W3c HTML5 spec simply proposed a datetime input. Starting with iOS 5, Mobile Safari began displaying a UI for that input that matched the one you’d find in native apps. Other mobile browsers quickly followed suit.

Later, datetime was removed from the HTML5 draft spec in favor of combining individual date and time inputs to prompt users for a date/time value with two separate inputs. While reducing the number of new input types makes some sense, it ignores the utility of showing the combined date/time widget that’s already present and familiar on mobile devices.

Next, the datetime-local input was added to the spec to replace the void that removing datetime left. The new input would be similar to the old one, but lacking the notion of a time zone offset.

In late 2014, the W3C decided to drop datetime-local from the recommendation HTML5 spec because it could lead to confusion. However, the dominant mobile browsers (i.e. Mobile Safari and Chrome) had already implemented datetime-local and made it a de facto standard. So, the w3C relented and added it back to the latest recommendation draft.

Adding to the confusion a bit more, Apple still lists both datetime and datetime-local as supported input types for iOS 5.0 and later. That’s not exactly the case though. As of iOS 7, Mobile Safari started showing its native interface for datetime-local inputs and dropped support for datetime inputs at the same time. As with any input type that a browser doesn’t have enhanced support for, datetime inputs started falling back to plain text type fields on iOS 7.

Long story short, you must use datetime-local for iOS 7+ (at least through the current version of 8.1.3 as I write this) and it’s helpful to understand that the “local” means the input is time zone agnostic.

like image 82
Martin Vseticka Avatar answered Oct 07 '22 05:10

Martin Vseticka