WEBVTT 0 00:00.380 --> 00:01.280 Woohoo. 1 00:01.370 --> 00:07.460 I'm super, super excited to get into this lecture because it can get quite complex when dealing with 2 00:07.460 --> 00:08.890 dates and times. 3 00:08.900 --> 00:15.020 In fact, gathering date and time values has traditionally been a nightmare for web developers. 4 00:15.110 --> 00:18.740 But you may be thinking I'm overexaggerating. 5 00:18.740 --> 00:19.790 Why is it so difficult? 6 00:19.790 --> 00:25.490 Well, how do you express the last minute of the previous millennium, for example? There are different formats, 7 00:25.490 --> 00:28.430 there are different ways you can display it. 8 00:28.430 --> 00:33.380 And traditionally, it's been really confusing because different operating systems display things in 9 00:33.380 --> 00:34.130 different ways. 10 00:34.130 --> 00:40.700 Users have different settings and it can easily become a nightmare and dates can get muddled up. 11 00:40.700 --> 00:48.380 As I'm sure you can agree with me, it's important to have a good calendar selection UI that enables 12 00:48.380 --> 00:54.230 users to select dates without them having to switch over to a native calendar app or potentially entering 13 00:54.230 --> 00:58.220 them in different formats that are hard for us as developers to parse. 14 00:58.220 --> 01:06.150 And this is exactly why HTML5 gave us different types, different type values for creating inputs for 15 01:06.150 --> 01:07.800 dates and times. 16 01:07.800 --> 01:09.270 "Well, Clyde, what are they?" 17 01:09.480 --> 01:10.260 Very good question. 18 01:10.260 --> 01:11.100 Let's have a look. 19 01:13.110 --> 01:20.580 HTML5 is introduced these types to help us with dates, date, time, month, datetime-local and 20 01:20.580 --> 01:21.090 week. 21 01:21.090 --> 01:27.840 And the promise here is that these new field types will enable the browser to provide a standardized, 22 01:27.840 --> 01:36.240 accessible and consistent user interface to capture dates and times from the user with ease. 23 01:36.450 --> 01:38.810 This really is important my students. 24 01:38.820 --> 01:39.620 Why? 25 01:39.630 --> 01:45.990 Well, we know that date and time formats vary world over, right, based on both language and location. 26 01:45.990 --> 01:54.330 So having the browser give us an unambiguous technical date format really is an ideal solution. 27 01:55.920 --> 01:56.340 Okay. 28 01:56.370 --> 01:57.720 So, how do we set this up? 29 01:57.720 --> 01:58.740 How does it work? 30 01:58.830 --> 02:00.390 It's very, very easy. 31 02:00.840 --> 02:05.800 We know that date and time controls are created using the input element. 32 02:05.820 --> 02:11.340 We just need to set an appropriate value for the type attribute, depending on whether you want to collect 33 02:11.340 --> 02:13.410 dates, times or both. 34 02:13.830 --> 02:14.070 Okay. 35 02:14.070 --> 02:15.180 Well, let's look at some examples. 36 02:15.180 --> 02:20.280 Let's start by first looking at the input type set to date. 37 02:22.670 --> 02:30.050 Firstly, it lets the user enter a date, either with a text box that validates the inputs or a special 38 02:30.050 --> 02:35.800 date picker interface, and the resulting value includes a year, month and day. 39 02:35.810 --> 02:43.970 But importantly, it does not include the time. Developers like the specific type generally because the 40 02:43.970 --> 02:52.820 date value a user enters will be mapped to the ISO date format, which is used in most technical contexts. 41 02:52.850 --> 02:56.680 The last point there is very, very important. 42 02:56.690 --> 03:01.520 The displayed date format will differ from the actual value. 43 03:01.550 --> 03:08.540 The displayed date is formatted based on the locale of the user's browser, but the parsed value - that 44 03:08.540 --> 03:15.680 value attribute - will always be formatted YYYY/MM/DD just like you see 45 03:15.680 --> 03:19.510 below, on the 31st of December 2099. 46 03:19.520 --> 03:20.660 Is it making sense? 47 03:20.810 --> 03:21.560 I hope so. 48 03:21.590 --> 03:22.920 Let's move on now. 49 03:22.920 --> 03:25.950 I want to look at the type of datetime-local. 50 03:25.950 --> 03:27.150 What is that all about? 51 03:28.110 --> 03:29.250 Well is pretty cool. 52 03:29.280 --> 03:35.250 This creates a widget letting the user enter a date and a time. And by "time", I just mean hours and 53 03:35.250 --> 03:39.270 minutes. Seconds are not supported with this type. 54 03:39.270 --> 03:45.210 Something to bear in mind is that the control's UI does vary in general from browser to browser, and 55 03:45.210 --> 03:48.030 at the moment support is kind of patchy. 56 03:48.030 --> 03:53.070 But I mean really, browsers are very, very quick to implement the latest standards, so I don't suspect 57 03:53.070 --> 03:54.740 that will be much of an issue much longer. 58 03:54.750 --> 03:57.240 What is the intention of this time? 59 03:57.240 --> 04:03.000 Well, at its core, the control is intended to simply represent a local date and time. 60 04:03.000 --> 04:10.320 Here, we are in the situation again where the displayed date and time format to the user will differ or 61 04:10.320 --> 04:13.680 may differ from the actual value sent to the server. 62 04:13.680 --> 04:19.560 For example, if we look at that value on the screen here of 31st of December 2030, that might be what 63 04:19.560 --> 04:20.400 the user sees. 64 04:20.400 --> 04:26.730 And when they submit that to the server, it's going to be converted to the following format. 65 04:26.760 --> 04:29.360 Of course it's submitted to the server name=value pairs. 66 04:29.360 --> 04:35.710 So let's say it's name attribute is yourDate, it's value is going to be converted to the format ... 67 04:35.710 --> 04:41.530 YYYY/MM/DD, then a capital T and the hours and the minutes. 68 04:41.830 --> 04:44.560 This is how it's going to look when it's sent to the server. 69 04:44.560 --> 04:49.840 And as you can see with this example, what's submitted to the server is different to what the user 70 04:49.840 --> 04:51.850 sees on the front end. 71 04:51.850 --> 04:54.420 So it's just something for you to bear in mind. 72 04:54.430 --> 04:56.800 All right, let's move on to another type. 73 04:56.800 --> 04:59.560 This time I want to look at type of month. 74 04:59.560 --> 05:00.880 What is this all about? 75 05:04.160 --> 05:05.200 Well, its very intuitive. 76 05:05.210 --> 05:07.760 It just lets the user enter a month and a year. 77 05:07.760 --> 05:15.110 And like the previous type, the UI varies from browser to browser, and support is currently touch 78 05:15.110 --> 05:15.470 and go. 79 05:15.500 --> 05:22.400 It's a bit patchy and the format submitted to the server is always in the format of YYYY/ 80 05:22.430 --> 05:23.810 MM. 81 05:23.960 --> 05:29.630 So again, we're in the situation of what the user sees is not necessarily what's submitted to the server. 82 05:29.660 --> 05:30.380 Okie dokie. 83 05:30.410 --> 05:31.190 Let's move on. 84 05:31.190 --> 05:33.860 I want to look now at the type of week. 85 05:37.390 --> 05:45.130 Input where its type is set to week, creates a widget to display and pick a week number and its year. 86 05:45.160 --> 05:49.390 And just remember that weeks start on Monday and run to Sunday. 87 05:49.390 --> 05:55.270 And another slight nuance is that the first week one of each year contains the first Thursday of that 88 05:55.270 --> 06:00.460 year, which may not include the first day of the year, or it may include the last few days of the 89 06:00.460 --> 06:01.170 previous year. 90 06:01.180 --> 06:02.170 Just bear that in mind. 91 06:02.200 --> 06:03.760 A slight nuance. 92 06:03.760 --> 06:10.480 And similarly to the other types we've been looking at, what the user sees may not be submitted to 93 06:10.480 --> 06:13.420 the server in the exact same format, right. Here, 94 06:13.420 --> 06:19.510 it's always going to be submitted as YYYY-W and then the week. 95 06:19.540 --> 06:20.380 Got it. 96 06:20.410 --> 06:20.980 Great. 97 06:22.660 --> 06:29.350 Finally, I want to look at input where its type is set to time. Here a widget is created that allows 98 06:29.350 --> 06:32.380 the user to display and pick a time value. 99 06:32.380 --> 06:39.710 Support of this type is good across all modern browsers, and while time may display in a 12 hour format, 100 06:39.740 --> 06:47.600 the value returned is always going to be in a 24 hour format regardless of the operating system of the 101 06:47.600 --> 06:48.830 user's machine. 102 06:49.010 --> 06:54.800 If the time the user selects includes seconds, the format is always going to be submitted to the server 103 06:54.830 --> 06:59.810 as HH:MM:SS. 104 06:59.810 --> 07:05.660 But one thing to bear in mind, though, is when a form, including a time input, is submitted, the 105 07:05.660 --> 07:11.000 value has to be URL encoded before being sent to the server. 106 07:11.000 --> 07:18.500 So we know all those little colons are going to be converted to %3A. Remember, we went 107 07:18.500 --> 07:22.100 through all of that URL encoding stuff in previous sections. 108 07:22.580 --> 07:23.360 So there we go. 109 07:23.360 --> 07:25.580 We see it very practically. 110 07:26.030 --> 07:28.340 Oh, I know we've done a lot, seriously. 111 07:28.340 --> 07:30.620 And that's why sometimes you just got to have some coffee ☕. 112 07:30.620 --> 07:31.880 You just got to get through it. 113 07:32.630 --> 07:34.130 I know it's a lot to take in. 114 07:34.130 --> 07:40.310 Just remember, traditionally working with dates has been really hard for developers and that's why 115 07:40.310 --> 07:46.010 we've got all these different types that the browsers have tried to implement to give us the ability 116 07:46.010 --> 07:52.520 to give the user the right format or the right type of date to submit to a server. 117 07:52.760 --> 07:54.620 And what are a few other things I can mention? 118 07:54.620 --> 08:02.600 Well firstly, all date and time widgets can be constrained by using the min and max attributes and 119 08:02.600 --> 08:05.810 further constraining using the step attribute. 120 08:05.840 --> 08:09.770 We've already seen these in action, but I will show you an example quickly of how it works. 121 08:09.770 --> 08:13.880 And the final thing I want to mention is just kind of browser support. 122 08:13.880 --> 08:14.840 Where are we with that? 123 08:14.840 --> 08:21.050 Well, the crux of it is that date and time pickers don't have great support when it comes to browsers 124 08:21.080 --> 08:21.980 at the moment. 125 08:21.980 --> 08:28.700 At the time of this video, Chrome, Edge and Opera support these very well, but it's not really much 126 08:28.700 --> 08:30.560 support when it comes to Internet Explorer. 127 08:30.560 --> 08:34.850 Safari has some support but not desktop support. 128 08:34.850 --> 08:39.500 And what about Firefox? Well, Firefox only supports time and date. 129 08:39.500 --> 08:41.810 So as you can see, it's kind of patchy, right? 130 08:41.810 --> 08:49.160 And one solution to this is to use, say, a JavaScript library in order to custom design your own date 131 08:49.160 --> 08:49.670 picker. 132 08:49.700 --> 08:54.980 But anyway, now at least you know all the different types when it comes to dates and times. 133 08:55.340 --> 08:58.130 Hope you're having a lot of fun and I'll see you in the next lecture.