22

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?

BenMorel
  • 34,448
  • 50
  • 182
  • 322
AgelessEssence
  • 6,395
  • 5
  • 33
  • 37

4 Answers4

25

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.

Community
  • 1
  • 1
MartyIX
  • 27,828
  • 29
  • 136
  • 207
19

The difference between the two is that the datetime-local input does not include the time zone. If the time zone is not important to your application, use datetime-local.

Some browsers are still trying to catch up to the datetime input type. Firefox 7 has still not shown any progress in this area. Instead, set up your own using three select fields with options that are populated in relation to today's date. That gives you a lot more control over how it actually looks and behaves, and you won't run the risk of a lot of your users seeing only regular text fields and having to guess at how to enter information into them.

Adam
  • 3,668
  • 6
  • 30
  • 55
  • in this specific case, i only wanna to get a timestamp value "YY-MM-DD HH:MM:SS", i think datetime-local will be fine. – AgelessEssence Oct 19 '11 at 01:10
  • this will be used in a internal comercial app, where one of the requirements is Opera Browser... currently, we have to use http://www.dynarch.com/projects/calendar/download/1.7/ to display date time fields, but now we like the simplicity of set "" ( much more compact/elegant code ) – AgelessEssence Oct 19 '11 at 01:10
  • 1
    There are ways to make custom tags with javascript that you could use as inputs for date, giving you ultimate control over the styling of the input. Otherwise, you'll be dealing with having to show people how to enter the information in a potentially cryptic way. This usually presents the user with usability issues, and unless they already have a decent understanding of computers and forms, they will have a hard time entering the information correctly, which makes for nightmarish validation. Best to keep it as simple as possible for the user. – Adam Oct 19 '11 at 06:09
  • good point, i still using "" cuz is part of HTML5 specification, and early or late, all browsers should support it AS SHOULD BE... currently Opera Browser displays a nice calendar: http://www.html5tutorial.info/html5-date.php – AgelessEssence Oct 19 '11 at 19:58
1

Here's a more recent (from Apr. 23, 2017) and definitive answer (in bold), per MDN:

<input type="datetime">

Obsolete

This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.

The HTML was a control for entering a date and time (hour, minute, second, and fraction of a second) as well as a timezone. This feature has been removed from WHATWG HTML, and is no longer supported in browsers.

Instead, browsers are implementing (and developers are encouraged to use) the datetime-local input type.

Source

Community
  • 1
  • 1
youngrrrr
  • 3,044
  • 3
  • 25
  • 42
1

Have a look at the HTML5 date input fields at iOS5, or at Google Chrome for Android, it is pretty cool. Both have support for the types date, datetime, datetime-local, time, month, only week is missing. Especially for mobile/touch clients the support of the new input times is quite important. For my application I will show a js/html based calendar (like dynarch) or the html5 input field depending on the client.

Konstantin Breu
  • 11
  • 1
  • at the moment, i use dynarch widget calendar too, but will be nice when that things come to an end ( supported by default ) – AgelessEssence Feb 23 '12 at 08:41