Html datetime local текущее время
A DOMString representing the value of the date entered into the input. You can set a default value for the input by including a date inside the value attribute, like so:
One thing to note is that the displayed date format differs from the actual value — the displayed date format will be chosen based on the set locale of the user’s operating system, whereas the date value is always formatted yyyy-mm-ddThh:mm . When the above value submitted to the server, for example, it will look like partydate=2017-06-01T08:30 .
Note: Also bear in mind that if such data is submitted via HTTP GET , the colon character will need to be escaped for inclusion in the URL parameters, e.g. partydate=2017-06-01T08%3A30 .
You can also get and set the date value in JavaScript using the HTMLInputElement.value property, for example:
var dateControl = document.querySelector('input[type="datetime-local"]'); date.value = '2017-06-01T08:30'; Using datetime-local inputs
Date/time inputs sound convenient at first glance — they provide an easy UI for choosing dates and times, and they normalize the data format sent to the server, regardless of the user’s locale. However, there are issues with because of the limited browser support. We’ll look at basic and more complex uses of , then offer advice on mitigating the browser support issue later on (see Handling browser support).
Basic uses of datetime-local
Setting maximum and minimum dates and times
You can use the min and max attributes to restrict the dates/times that can be chosen by the user. In the following example we are setting a minimum datetime of 2017-06-01T08:30 and a maximum datetime of 2017-06-30T16:30 :
- Only days in June 2017 can be selected — only the «days» part of the date value will be editable, and dates outside June can’t be scrolled to in the datepicker widget.
- Depending on what browser you are using, you might find that times outside the specified values might not be selectable in the time picker (e.g. Edge), or invalid (see Validation) but still available (e.g. Chrome).
Note: You should be able to use the step attribute to vary the number of days jumped each time the date is incremented (e.g. maybe you only want to make Saturdays selectable). However, this does not seem to work effectively in any implementation at the time of writing.
Controlling input size
doesn’t support form sizing attributes such as size . You’ll have to resort to CSS for sizing needs.
Setting timezones
One thing the datetime-local input type doesn’t provide is a way to set the timezone/locale of the datetime. This was available in the datetime input type, but this type is now obsolete, having been removed from the spec. The main reasons why this was removed are a lack of implementation in browsers, and concerns over the user interface/experience. It is easier to just have a control (or controls) for setting the date/time and then deal with the locale in a separate control.
For example, if you are creating a system where the user is likely to already be logged in, with their locale already set, you could provide the timezone in a hidden input type. For example:
On the other hand, if you were required to allow the user to enter a timezone along with a datetime entry, you could provide a means of inputting a timezone, such as a element:
In either case, the timedate and timezone values would be submitted to the server as separate data points, and then you’d need to store them appropriately in the database on the server-side.
Note: The above code snippet is taken from All world timezones in an HTML select element.
Validation
By default, does not apply any validation to entered values. The UI implementations generally don’t let you enter anything that isn’t a datetime — which is helpful — but you can still not fill in a datetime and submit, or enter an invalid datetime (e.g. the 32th of April).
You can use min and max to restrict the available dates (see anch(«Setting maximum and minimum dates»)), and in addition use the required attribute to make filling in the date mandatory. As a result, supporting browsers will display an error if you try to submit a date that is outside the set bounds, or an empty date field.
Let’s look at an example — here we’ve set minimum and maximum datetimes, and also made the field required:
If you try to submit the form with an incomplete date (or with a date outside the set bounds), the browser displays an error. Try playing with the example now:
Here’s’a screenshot for those of you who aren’t using a supporting browser:
Here’s the CSS used in the above example. Here we make use of the :valid and :invalid CSS properties to style the input based on whether or not the current value is valid. We had to put the icons on a next to the input, not on the input itself, because in Chrome the generated content is placed inside the form control, and can’t be styled or shown effectively.
div < margin-bottom: 10px; display: flex; align-items: center; >label < display: inline-block; width: 300px; >input:invalid+span:after < content: '✖'; padding-left: 5px; >input:valid+span:after
Important: HTML form validation is not a substitute for scripts that ensure that the entered data is in the proper format. It’s far too easy for someone to make adjustments to the HTML that allow them to bypass the validation, or to remove it entirely. It’s also possible for someone to simply bypass your HTML entirely and submit the data directly to your server. If your server-side code fails to validate the data it receives, disaster could strike when improperly-formatted data is submitted (or data which is too large, is of the wrong type, and so forth).
Handling browser support
As mentioned above, the major problem with using date inputs at the time of writing is browser support — only Chrome/Opera and Edge support it on desktop, and most modern browsers on mobile. As an example, the datetime-local picker on Firefox for Android looks like this:
Non-supporting browsers gracefully degrade to a text input, but this creates problems both in terms of consistency of user interface (the presented control will be different), and data handling.
The second problem is the most serious — as we mentioned earlier, with a datetime-local input the actual value is always normalized to the format yyyy-mm-ddThh:mm . With a text input on the other hand, by default the browser has no recognition of what format the date should be in, and there are lots of different ways in which people write dates and times, for example:
- ddmmyyyy
- dd/mm/yyyy
- mm/dd/yyyy
- dd-mm-yyyy
- mm-dd-yyyy
- mm-dd-yyyy hh:mm (12 hour clock)
- mm-dd-yyyy hh:mm (24 hour clock)
- etc.
One way around this is to put a pattern attribute on your datetime-local input. Even though the datetime-local input doesn’t use it, the text input fallback will. For example, try viewing the following demo in a non-supporting browser:
If you try submitting it, you’ll see that the browser now displays an error message (and highlights the input as invalid) if your entry doesn’t match the pattern nnnn-nn-nnTnn:nn , where n is a number from 0 to 9. Of course, this doesn’t stop people from entering invalid dates, or incorrectly formatted dates and times.
And what user is going to understand the pattern they need to enter the time and date in?
div < margin-bottom: 10px; >input:invalid + span < position: relative; >input:invalid + span:after < content: '✖'; position: absolute; right: -18px; >input:valid + span < position: relative; >input:valid + span:after
The best way to deal with dates in forms in a cross-browser way at the moment is to get the user to enter the day, month, year, and time in separate controls ( elements being popular — see below for an implementation), or use JavaScript libraries such as jQuery date picker, and the jQuery timepicker plugin.
Examples
In this example we create two sets of UI elements for choosing datetimes — a native picker, and a set of five elements for choosing dates and times in older browsers that don’t support the native input.