Woohoo.
I'm super, super excited to get into this lecture because it can get quite complex when dealing with
dates and times.
In fact, gathering date and time values has traditionally been a nightmare for web developers.
But you may be thinking I'm overexaggerating.
Why is it so difficult?
Well, how do you express the last minute of the previous millennium, for example? There are different formats,
there are different ways you can display it.
And traditionally, it's been really confusing because different operating systems display things in
different ways.
Users have different settings and it can easily become a nightmare and dates can get muddled up.
As I'm sure you can agree with me, it's important to have a good calendar selection UI that enables
users to select dates without them having to switch over to a native calendar app or potentially entering
them in different formats that are hard for us as developers to parse.
And this is exactly why HTML5 gave us different types, different type values for creating inputs for
dates and times.
"Well, Clyde, what are they?"
Very good question.
Let's have a look.
HTML5 is introduced these types to help us with dates, date, time, month, datetime-local and
week.
And the promise here is that these new field types will enable the browser to provide a standardized,
accessible and consistent user interface to capture dates and times from the user with ease.
This really is important my students.
Why?
Well, we know that date and time formats vary world over, right, based on both language and location.
So having the browser give us an unambiguous technical date format really is an ideal solution.
Okay.
So, how do we set this up?
How does it work?
It's very, very easy.
We know that date and time controls are created using the input element.
We just need to set an appropriate value for the type attribute, depending on whether you want to collect
dates, times or both.
Okay.
Well, let's look at some examples.
Let's start by first looking at the input type set to date.
Firstly, it lets the user enter a date, either with a text box that validates the inputs or a special
date picker interface, and the resulting value includes a year, month and day.
But importantly, it does not include the time. Developers like the specific type generally because the
date value a user enters will be mapped to the ISO date format, which is used in most technical contexts.
The last point there is very, very important.
The displayed date format will differ from the actual value.
The displayed date is formatted based on the locale of the user's browser, but the parsed value - that
value attribute - will always be formatted YYYY/MM/DD just like you see
below, on the 31st of December 2099.
Is it making sense?
I hope so.
Let's move on now.
I want to look at the type of datetime-local.
What is that all about?
Well is pretty cool.
This creates a widget letting the user enter a date and a time. And by "time", I just mean hours and
minutes. Seconds are not supported with this type.
Something to bear in mind is that the control's UI does vary in general from browser to browser, and
at the moment support is kind of patchy.
But I mean really, browsers are very, very quick to implement the latest standards, so I don't suspect
that will be much of an issue much longer.
What is the intention of this time?
Well, at its core, the control is intended to simply represent a local date and time.
Here, we are in the situation again where the displayed date and time format to the user will differ or
may differ from the actual value sent to the server.
For example, if we look at that value on the screen here of 31st of December 2030, that might be what
the user sees.
And when they submit that to the server, it's going to be converted to the following format.
Of course it's submitted to the server name=value pairs.
So let's say it's name attribute is yourDate, it's value is going to be converted to the format ...
YYYY/MM/DD, then a capital T and the hours and the minutes.
This is how it's going to look when it's sent to the server.
And as you can see with this example, what's submitted to the server is different to what the user
sees on the front end.
So it's just something for you to bear in mind.
All right, let's move on to another type.
This time I want to look at type of month.
What is this all about?
Well, its very intuitive.
It just lets the user enter a month and a year.
And like the previous type, the UI varies from browser to browser, and support is currently touch
and go.
It's a bit patchy and the format submitted to the server is always in the format of YYYY/
MM.
So again, we're in the situation of what the user sees is not necessarily what's submitted to the server.
Okie dokie.
Let's move on.
I want to look now at the type of week.
Input where its type is set to week, creates a widget to display and pick a week number and its year.
And just remember that weeks start on Monday and run to Sunday.
And another slight nuance is that the first week one of each year contains the first Thursday of that
year, which may not include the first day of the year, or it may include the last few days of the
previous year.
Just bear that in mind.
A slight nuance.
And similarly to the other types we've been looking at, what the user sees may not be submitted to
the server in the exact same format, right. Here,
it's always going to be submitted as YYYY-W and then the week.
Got it.
Great.
Finally, I want to look at input where its type is set to time. Here a widget is created that allows
the user to display and pick a time value.
Support of this type is good across all modern browsers, and while time may display in a 12 hour format,
the value returned is always going to be in a 24 hour format regardless of the operating system of the
user's machine.
If the time the user selects includes seconds, the format is always going to be submitted to the server
as HH:MM:SS.
But one thing to bear in mind, though, is when a form, including a time input, is submitted, the
value has to be URL encoded before being sent to the server.
So we know all those little colons are going to be converted to %3A. Remember, we went
through all of that URL encoding stuff in previous sections.
So there we go.
We see it very practically.
Oh, I know we've done a lot, seriously.
And that's why sometimes you just got to have some coffee â˜•.
You just got to get through it.
I know it's a lot to take in.
Just remember, traditionally working with dates has been really hard for developers and that's why
we've got all these different types that the browsers have tried to implement to give us the ability
to give the user the right format or the right type of date to submit to a server.
And what are a few other things I can mention?
Well firstly, all date and time widgets can be constrained by using the min and max attributes and
further constraining using the step attribute.
We've already seen these in action, but I will show you an example quickly of how it works.
And the final thing I want to mention is just kind of browser support.
Where are we with that?
Well, the crux of it is that date and time pickers don't have great support when it comes to browsers
at the moment.
At the time of this video, Chrome, Edge and Opera support these very well, but it's not really much
support when it comes to Internet Explorer.
Safari has some support but not desktop support.
And what about Firefox? Well, Firefox only supports time and date.
So as you can see, it's kind of patchy, right?
And one solution to this is to use, say, a JavaScript library in order to custom design your own date
picker.
But anyway, now at least you know all the different types when it comes to dates and times.
Hope you're having a lot of fun and I'll see you in the next lecture.