Mastering JavaScript Dates and Times – Fundamentals to Advanced Techniques

[00:00] Learn all about time handling in modern [00:02] web development with JavaScript. In this [00:05] comprehensive course, you will learn [00:07] about the notorious quirks of the native [00:09] date object, master global formatting [00:12] using the powerful Intel API, and [00:14] explore strategies for handling tricky [00:16] concepts like epoch time, time zones, [00:19] and daylight saving time. You will also [00:22] get a look at the upcoming temporal API [00:25] comparing it side by side with current [00:27] methods and learning how to implement it [00:29] using today's polyfills. Tapus created [00:33] this course. [00:40] Hello everyone, welcome back. If you [00:43] have worked with JavaScript for any [00:45] length of time, you have almost [00:47] certainly ran into dates and time. And [00:49] if you have worked with dates and time [00:51] for any length of time, you have [00:53] certainly thought about throwing your [00:55] laptop across the room. Dates and times [00:58] are one of those topic that looks so [01:00] simple on the surface. But once you [01:02] deploy your application on the [01:04] production and somebody your user access [01:07] that application from another side of [01:09] the globe, they start seeing something [01:11] off. Maybe by a day, maybe by few hours, [01:14] maybe things are broken on February 29th [01:17] and you start scratching your head [01:19] wondering why is this happening. So I [01:21] thought why not address that problem. [01:23] Hence we are starting a complete [01:26] comprehensive course on JavaScript date [01:29] and time. This is going to be a long [01:30] course. That's the reason I'm breaking [01:32] into multiple parts. In the part one, we [01:35] are going to demystify everything about [01:37] dates in JavaScript. We are not going to [01:40] talk about only APIs rather we are going [01:42] to talk about the why part the [01:44] background part the fundamental part and [01:47] that most of the developers miss out [01:48] today and that's the whole reason for [01:51] introducing a lot of production level [01:53] bug by the end of this part one you will [01:55] have a rock solid mental model to [01:57] address any date and time related issues [01:59] in JavaScript with confidence so let's [02:02] go and before we get started here is [02:04] something about me I am Tapus a software [02:06] engineer with 20 plus years of real [02:09] world experience in building and [02:10] debugging production system. On this [02:12] channel, we go beyond tutorial. We [02:15] master fundamentals, we fix real bugs [02:18] and we think like engineers. If you are [02:20] someone who is serious about leveling up [02:22] your dev career, just hit the subscribe. [02:25] Most people think that date and time are [02:28] simple linear things. If the clock hits [02:30] 3 p.m., it means it's 3 p.m. and end of [02:33] the story. But when you are writing [02:35] software that has to be used by your [02:38] user from different parts of the globe [02:40] on different devices they are in [02:42] different time zones considering [02:44] daylight savings appear and etc. My [02:46] friend time is not that simple. It gets [02:49] complicated very very soon. Let me take [02:51] an example. Let's assume that you are [02:54] building a calendar app. A user in New [02:56] York schedules a meeting for 900 a.m. [02:59] tomorrow. And then another user in [03:02] London accepts that meeting. A third [03:04] user in Tokyo joins the meeting to see [03:07] who actually join at 9:00 a.m. So here [03:11] what does 900 a.m. means for each of [03:14] these individual who are trying to [03:17] attend this meeting from different [03:18] geographic location. What does even [03:20] tomorrow means to this Tokyo guy? These [03:22] are not age cases. These are everyday's [03:25] problem and to understand this and to [03:28] fix bugs around this you have to [03:30] understand date and time ground up. [03:32] That's exactly we are going to do in [03:34] this course. But what is the core [03:35] problem? The core problem is time is [03:38] relative. What does it mean? It means [03:40] there is no single now moment that [03:43] everyone on this earth can agreed upon [03:45] simultaneously. See the earth is round [03:48] and sun that falls and shines on [03:51] different parts of the globe on [03:53] different times and we humans what we [03:55] have done we have divided the planet [03:56] into different time zones so that we can [03:59] make use of the civil time useful to our [04:01] daily life. So it means the current [04:04] moment now has a completely different [04:07] time representation depending on where [04:10] you are at this point on the earth [04:12] geographically. While recording this [04:14] video, it's 3:00 p.m. in New York, it's [04:17] 8:00 p.m. in London, it's 9:00 p.m. in [04:19] Berlin, and it is 4:00 a.m. next day in [04:23] Tokyo. That's exactly what we are [04:25] talking about. Same moment, different [04:27] representation. And this is the exact [04:29] problem that we face so many issues with [04:32] date and time in programming. See the [04:35] computers were invented with globally [04:37] distributed usage in mind. But the first [04:40] operating system that was invented was [04:42] designed for a single machine and for a [04:45] single location. Early unique systems [04:47] stored the time in local time and when [04:50] internet eventually started growing this [04:53] started creating the problem because [04:55] your local time may not be same as my [04:57] local time. This become a serious [04:59] problem and to add to that there are few [05:01] more problems and this is the part that [05:03] you must note down at least the [05:04] pointers. The first problem time zones [05:07] don't just add and subtract a whole [05:09] hours. It might be in minutes like 30 [05:12] minutes, 45 minutes. For example, if you [05:14] take India and Bangladesh, they have the [05:16] time zone offset difference of just 30 [05:18] minutes. Maybe for some other countries [05:20] 15 minutes, 45 minutes. Okay, so these [05:21] are the things that you have to keep in [05:23] mind when you are dealing with date and [05:24] time. Point number two, daylight savings [05:27] can move the dates forward or backward. [05:30] And the more problematic part is [05:32] daylight saving is not applicable for [05:34] all the countries on the globe. Point [05:36] number three, I'm not sure if you're [05:38] aware that government can change the [05:40] time zone rules. Sometimes they can do [05:43] it with very very little time notice. [05:45] Point number four, all of us know that [05:47] the months are having different lengths. [05:48] Some months are in 28 days, sometime 29 [05:51] days, sometime 30 days, sometime 31 [05:53] days. And there is something called leap [05:54] year, right? For that we get one day [05:57] extra in 4 years. we have February 29th [06:00] in every four years. So when you're [06:01] dealing with date and time in [06:03] programming, you have to consider all [06:05] these pointers so that it doesn't break [06:08] anything in your application for a [06:11] customer because if the date and time is [06:13] broken, it's actually going to cost [06:15] money. We all know right time is money. [06:17] Now with all this knowledge that we have [06:19] gathered, it's time that we learn the [06:21] meaning of certain jarens, certain [06:24] words, certain phrases. For example, [06:25] epoch time, UTC, EST. There are variety [06:29] of things that we'll be learning and you [06:31] must understand each of these thing very [06:33] well to use date and time in your [06:35] JavaScript programming effectively. Let [06:37] us first start with epoch time. You [06:39] would have heard about this already. [06:41] What is epoch time? The epoch time exist [06:44] because of this particular thing that [06:46] time is relative. We spoke about it, [06:48] right? My now is not equal to your now. [06:52] If we are not situated in the same [06:54] geographic location, it may not be it [06:56] may be entirely different. But to [06:59] calculate the date and time, programmers [07:01] needed a universal reference point. [07:04] Let's create one. Let's assume that this [07:06] is that universal reference point that [07:09] everyone on this earth, every [07:11] programmer, every software developer on [07:13] this earth will refer this as a starting [07:16] point. And this is a single unambiguous [07:19] number that represents a specific moment [07:23] in time. Regardless wherever you are [07:26] situated on this earth, we should always [07:27] treat this as a starting point. And this [07:31] particular starting point is called [07:32] epoch. Now what is this value or which [07:35] particular date and time this particular [07:37] epoch is set to? It is set to 1st of [07:40] January 1970 at exactly 000000 [07:46] hours. So from this moment every second [07:49] that passes gets a unique number in [07:52] milliseconds. It means that the time [07:55] stamp zero is January 1st 1970 at [08:00] exactly 000000 [08:02] hours of 1 million is about 11.5 days [08:06] later. Another example, a time stamp of [08:08] this big number could signify the year [08:11] 2023. Now, how is this happening and [08:13] what are these numbers? We are going to [08:15] learn everything. But for now, remember [08:17] that for everyone, every programmer on [08:19] this earth, we need a single unambiguous [08:22] reference point. And this reference [08:24] point is starting from January 1st, 1970 [08:29] exactly at 000000 hours. And once you go [08:33] in future, you go in future in [08:35] milliseconds. And with that milliseconds [08:37] value from this reference points which [08:39] is standing on zero you can calculate [08:42] what is the amount of time that you have [08:44] progressed. If you can calculate it in [08:46] milliseconds you can convert it into [08:48] second. You can convert it into the [08:49] minutes then to hour then to days and so [08:52] on. Milliseconds we also symbolize it [08:56] with ms in programming. Now can you [08:58] guess why this representation in [09:01] JavaScript is in milliseconds not in [09:03] second? Why? Because there are many [09:04] operations we do in programming that may [09:07] happen in milliseconds. For example, [09:08] measuring performances, those animation [09:11] frames. That's the reason JavaScript use [09:13] this tweak to represent this time offset [09:16] always in milliseconds. Now, this might [09:18] come in your mind as it came in my mind [09:20] also. Why January 1st, 1970 is a [09:24] starting point? Why exactly? Honestly, [09:26] um what I found with my research that it [09:28] is somewhat an arbitrary number. The [09:30] Unix operating system was being [09:32] developed in 19607s that time and [09:36] engineers needed a starting point that [09:38] time. That's how the year 1970 came into [09:41] the picture. It came into the picture [09:42] more because of the simplicity than [09:44] anything else. So if you have ever [09:46] wondered like why it is January 1st [09:48] 1970, there is really no deeper thought [09:51] and meaning. It probably it most [09:53] probably is because some folks thought [09:56] that that point in time this is the [09:57] simplistic thing to do. The next big [09:59] question, what's the difference between [10:01] a time stamp and a time zone? Often [10:03] developers get confused with that. A [10:05] time stamp is an absolute point in time [10:09] that is independent of location. Here [10:11] the time stamp is zero. You see over [10:13] here zero, that universal point. Here [10:16] the time stamp is 1 million. Here the [10:19] time stamp is this big number. So this [10:21] is what the time stamp is. It's a single [10:24] point absolute number. And this time [10:26] stamp absolute point in time is always [10:30] measured from January 1st 1970 at [10:33] exactly 000000 [10:35] hours. So here this number is a time [10:37] stamp. Zero is a time stamp. This big [10:39] number is a time stamp. And this time [10:41] stamp in JavaScript is always always [10:44] represented in milliseconds number. Then [10:47] what is a time zone? Time zone is a [10:50] different kind of rule set by human set [10:52] by us to represents different kind of [10:56] time for a specific region. Again, I'll [11:00] go deeper into time zone when we start [11:02] coding. But remember the difference [11:04] between the time stamp and time zone. [11:05] Time stamp doesn't have any time zone. [11:08] To calculate a particular time zones [11:10] time, you will need time stamp value. We [11:13] will learn all these things together. So [11:15] by definition, time stamp is what? It [11:18] represents a specific moment in time and [11:21] the unit is UTC. A time zone is [11:24] something which is a defined rule by us [11:26] for a specific region to communicate the [11:29] time and the time differences between [11:32] various regions. This is the difference. [11:33] So we got another term now is called [11:35] UTC. What is UTC? UTC actually stands [11:38] for coordinated universal time. Now if [11:41] you take this coordinated universal time [11:44] and if you put the abbreviation it [11:46] should be like C U T but why it is UTC. [11:50] So if you go back to the history as I [11:52] was researching that abbreviation never [11:55] matches only because the English and [11:58] French people when they were deciding [12:00] this they came together and they agreed [12:02] upon something called UTC that's the [12:04] primary reason and from then it become [12:06] the primary standard for the whole world [12:09] to use for time stamp so imagine UTC is [12:13] the master clock of the internet it keep [12:16] ticking it keeps ticking starting from [12:17] this zero as it keeps ticking we tends [12:20] to go to the future a future time a [12:22] future date a future day a future hour [12:25] like that this UTC doesn't have any [12:28] daylight saving it doesn't have any leap [12:30] year it doesn't have any notion it just [12:33] keep shifting kept ticking to take us to [12:36] the future and that's the whole reason [12:37] that when you talk about a time stamp [12:39] this particular milliseconds value we [12:42] always put this UTC as a unit to say [12:45] that how much offset from this zero we [12:48] have come to the future so that we can [12:51] conclude a particular day, a particular [12:54] date, a particular time. I hope the UTC [12:56] is clear. Time stamp is always in UTC. [12:59] Why? Because time stamp doesn't have any [13:01] time zone. I mean universally there is [13:04] no New York time stamp. There is no [13:06] Tokyo time stamp. There is just one [13:08] number universally available. And using [13:11] that number you calculate the date and [13:13] time and etc. Now to bring these things [13:16] technically this is the whole reason [13:18] when you will be saving your date and [13:20] time information into a database you [13:23] must be saving it in UTC. It means you [13:26] will be saving a time stamp and when you [13:29] retrieve that and display that [13:31] information on the UI you will be [13:33] converting this timestamp information [13:36] into that particular UI's location's [13:40] local time. What does it mean? Imagine [13:42] we have two users. First user accessing [13:44] the application from India. The second [13:46] user accessing the same application from [13:49] France. There is a centralized DB which [13:51] is storing the information. Now this [13:53] application deals with date and time. [13:55] What we must be doing is like any date [13:58] and time information we store in the DB. [14:00] It must be stored in the epoch format [14:03] means this millisecond format in the UTC [14:08] time. Okay. This is why we call UTC [14:10] time. Whenever we call UTC time or the [14:12] epoch time, consider them as the same [14:15] thing we're talking about. We're talking [14:16] about the time stamp, not the exact [14:18] time. Okay? So, always store in epoch [14:21] time in UTC. But when we are retrieving [14:24] this and showing it in our application, [14:26] if we show this epoch time, it will be a [14:28] time like this doesn't make any sense to [14:30] any user. That means you have to convert [14:33] this time to something that makes sense [14:35] to this user. Maybe what you will be [14:37] doing, you have this epoch time. So with [14:39] this epoch time you can calculate from [14:41] January 1st 1970 which is like zero get [14:43] the millisecond then convert that [14:45] millisecond with your own programming [14:47] language to a particular date and time [14:49] that's fine but another additional thing [14:52] you have to do you have to take care of [14:54] which particular local this particular [14:57] user is using this application from [15:00] where is your client what is the time [15:02] zone of your client. So when you display [15:05] you have to display this epoch number [15:07] converted into that particular time zone [15:10] where your user is accessing the [15:12] application from. This is how if you [15:14] handle date and time your date and time [15:17] will be universal and it will be without [15:20] any kind of bug. Maybe the epoch time [15:22] representation is something like this [15:24] number and this number when we try to [15:27] display it could be 12:35 [15:32] p.m. in p.m. in India and morning 8:5 [15:35] a.m. in France and if you want to talk [15:38] about like why it is 12:35 p.m. in India [15:41] at the same time it is 8:5 a.m. In [15:43] France that is where the time zone comes [15:45] into picture because in India we follow [15:48] a time zone which is called Indian [15:50] standard time which is nothing but IST [15:53] and here this particular time in France [15:55] is another time zone called CCT. Okay. [15:58] So this is the time zone value. So it [16:00] means that wherever you are storing this [16:02] data from you are storing this in UTC [16:06] and then when you are retrieving and [16:07] going to display that you have to [16:09] translate that into the client specific [16:12] time zone that particular time. So this [16:15] is how you have to handle date and time. [16:17] We are going to see a lot of them with [16:19] coding in this part and in the [16:21] subsequent part. There are few more [16:22] terms you need to consider learning. You [16:24] know about the UTC. Now what is GMT? is [16:26] UTC and GMT are same. For the [16:29] programming context, you can take UTC [16:31] and GMT are same. There are tiny [16:33] differences that we are not bothered to [16:35] learn at this point in time. Let's [16:37] understand UTC and GMT are same. From [16:39] the time zone perspective, both UTC and [16:42] GMTs are in this particular time zone [16:46] offset. So, we'll be using them [16:48] interchangeably in our daily [16:49] programming. What is local time? Local [16:51] time is nothing but the time that you [16:52] are seeing on your clock. Now on my [16:54] clock there is a time that I'm seeing [16:56] being in India. In your clock you might [16:58] be seeing a completely different time [16:59] than what I am seeing right now and this [17:01] local time is always driven by the time [17:04] zone that we are in. Now there are [17:06] different kind of time zone and [17:07] different kind of time zone offset and [17:09] every time zone offset in the world is [17:11] defined as an offset from this UTC. So [17:14] if UTC starts with 000000 here are some [17:17] examples. For example, New York which is [17:20] having this EST time zone is UTC minus [17:23] 5. That means it is behind. London is [17:26] follows the UTC and GMT. So it is UTC [17:28] plus 000000. You are seeing that India [17:30] is + 530. Nepal is + 545. Japan is + 9. [17:36] In case you are interested, this is one [17:38] time zone map. You can see this world [17:39] map and it time zone. For example, India [17:41] I told like + 5:30. So it falls over [17:44] here. Right? If I click over here any of [17:47] the location it's on plus 530 like that [17:49] you can move move on the different part [17:52] of the world. Select any country and try [17:54] to find out what is the time zone that [17:56] it is falling into. So this is UTC which [17:59] is 0000. Now from this side of the earth [18:02] it will only increment on this side of [18:04] the earth it will only decrement. That's [18:06] how you can find different offset and on [18:09] those offset there will be a name for [18:11] individual time stamp. That's how it is. [18:13] If you are interested in time zone and [18:15] you want to kind of play around more [18:17] with it, the world's time zones are [18:19] maintained by the AA which is internet [18:22] assigned number authority and they call [18:24] it as TZ database. You can always come [18:26] here, you can download and you can start [18:28] looking into it. By the way, I provided [18:30] all this link into the description of [18:31] this video. So you can go ahead and [18:33] check it out any point in time. Now the [18:35] question is how JavaScript handle these [18:37] time zones? What's the support? [18:38] Unfortunately, very very unfortunately [18:40] it's a frustrating truth that the [18:42] built-in support in JavaScript is about [18:46] only two time zones is about UTC and [18:49] your local time zone for rest all the [18:51] time zone we are talking about you have [18:53] to do it in little bit hard way we are [18:55] going to learn many of these things in [18:57] the next part of it but I want to [18:59] provide you enough hint that what you're [19:01] going to deal with in JavaScript now I [19:03] think we had enough theory we have [19:05] learned a lot about date time history [19:09] some of these jarens terms how time [19:12] works how time zone works what are the [19:14] problem why this difficulty it's time to [19:16] start doing some code isn't it open up [19:19] your favorite code editor I'm just going [19:20] to open up VS code for myself let's [19:22] start coding as part of 40 days of [19:24] JavaScript repository I have created a [19:25] new folder called day 41 you will find [19:28] it again from the tapascript [19:29] organization this particular repository [19:31] please check it out I have created a [19:33] simple HTML so that I can attach this [19:35] JavaScript over here the Java basket [19:37] file where I'm going to write all my [19:40] code. So far I just have a console.log [19:43] file. Let's go live with this HTML. I [19:46] can see this HTML rendered over here. [19:48] And if I open up the Chrome debugger [19:50] tools, I'm able to see this console.log [19:52] that is coming from my JavaScript file [19:55] saying JavaScript date and time which is [19:58] here. So I'm all set to start coding. [20:00] The first thing that we'll start with is [20:02] called date object. The JavaScript date [20:05] object is a built-in object that [20:08] represents a single moment in time. [20:11] Whenever you are doing new date in [20:15] JavaScript to create an instance of the [20:17] date object, you get the time of that [20:21] particular moment. So you can do like [20:23] new date. This returns instance of the [20:26] date object of that particular moment [20:28] which we can call it as now. So I've [20:30] created a date object over here. Let me [20:32] now access it. For example, I'll do [20:34] console dot log of now. I see the [20:38] complete date and time representation of [20:41] that moment when I have printed or [20:43] executed that console.log of now. Just [20:46] take a note of this time 141459. If I [20:49] just refresh, it will change it changed [20:51] to 141548 [20:52] because that console.log of now got [20:55] executed when I refresh the browser. So, [20:58] it now captured the time of that [21:01] particular moment. Right? So now is [21:03] always about capturing the time of that [21:07] particular moment along with the date [21:09] and all other information. GMT plus 5:30 [21:12] is the time zone. You remember UTC or [21:15] GMT is 000. [21:17] So from there 5:30 means 5 and a half is [21:21] nothing but the IST Indian standard time [21:23] zone. So new date gives me the single [21:27] moment in time. However, you need to [21:29] understand that internally it stores [21:31] that single moment of time in a single [21:34] number and that number is represented in [21:37] millisecond since January 1st 1970 [21:42] 0 UTC correct. So the number that is [21:45] printed that particular moment number [21:47] with the date time zone etc. But [21:51] internally JavaScript stored that number [21:53] in a millisecond. The same millisecond [21:55] that we have seen from that particular [21:58] point of January 1st 1970. Okay, that's [22:01] how JavaScript manage it internally. Now [22:03] the question is how do you get that [22:05] millisecond number that internal [22:07] representation of this particular moment [22:09] that we have seen getting logged into [22:11] the console.log to get that JavaScript [22:14] provides a static method called now. [22:17] Let's do a console.log of date.now. So [22:20] if you invoke this particular static [22:22] method on date object you get the [22:25] millisecond representation of that [22:27] moment which was human readable way [22:30] represented using this particular now [22:33] variable. So if I see both this [22:34] console.log log I will clearly know the [22:36] first one is a human readable [22:38] representation of the current moment and [22:40] this is that millisecond representation [22:42] the U in UTC remember and this is the [22:46] difference between your this moment of [22:48] time and that January 1st 1970 [22:53] 0 UTC that's the difference in a [22:55] millisecond time of course there is [22:56] another way you can get the same [22:58] representation before date dot now got [23:00] added how people used to get you have [23:02] this now over here right so you can do [23:04] console dot log of now dot [23:09] get time. If you call this get time [23:11] method on this particular object [23:13] instance, this is going to give you the [23:15] exactly same value in milliseconds. The [23:17] date object constructor can also take an [23:20] argument. When the date object [23:21] constructor takes an argument like this, [23:24] what it returns? It means that you are [23:26] now giving that timestamp in UTC passing [23:30] that to the date object to get a date [23:32] representation back. So now if I do a [23:35] console.log [23:37] of D1 what it is going to return the D1 [23:41] is going to return the human readable [23:43] date time format along with the time [23:46] zone for this particular time stamp. I [23:48] can see it over here like it's Monday [23:50] January 15, 2024 sometime. So guys [23:53] question for you and if you know about [23:55] object references or if any of you have [23:57] gone through my 40 days of JavaScript [23:59] course already you should answer this. [24:01] Is it true or false this console.log log [24:03] what it is going to log is going to be [24:05] false right what we are doing here we [24:07] are equating the reference to the [24:09] different objects here D1 is a reference [24:12] to one object in memory here D2 is a [24:14] reference to another object in the [24:16] memory we are trying to equate those two [24:18] references even though the value that is [24:20] stored on those memory location are [24:23] exactly same but the references are [24:25] different right we know that we have [24:26] learned enough about it like memory [24:28] management and all the things so here it [24:30] is going to be a false. Then how are you [24:33] going to compare if these two dates are [24:35] same or not? The best way to compare is [24:38] take D1 call get time on top of this and [24:42] equate it of course triple equals D2 dot [24:46] get time. Okay, this is going to give [24:49] you a true or false. If it is true then [24:51] we're talking about the same time. If it [24:53] is false then we're talking about the [24:55] different time. Why? Because D1.get Get [24:57] time is of course going to give you a [24:59] millisecond representation in UTC of [25:02] that particular date and time. G2.get [25:04] time also going to do the same. Now [25:06] you're comparing from a zeroth point to [25:09] a certain offset in millisecond. From [25:11] the zerooth point to another offset in [25:14] millisecond. Now you are comparing and [25:16] saying two numbers that these two time [25:18] are exactly the same time or different [25:20] time. There are four ways you can create [25:22] dates in JavaScript. One way that we [25:25] have learned is using the new date this [25:28] constructor without passing any [25:29] argument. Okay, this is one way. Second [25:31] way we pass is like you can pass the [25:33] milliseconds since the epoch time which [25:35] is the zero. This is the millisecond [25:37] difference and you get a date. This is [25:39] very useful for reconstructing a date [25:41] from a stored timestamp. I have already [25:44] communicated that you should be storing [25:46] the date and time in the UTC timestamp [25:50] in your database. So imagine that you're [25:52] retrieving this time stamp from your [25:54] database. You can pass it to this new [25:55] date constructor and you can actually [25:57] get the date. What happen if you put a [26:00] negative value over here? I'll leave it [26:01] to you. Try out a negative value and see [26:03] what happens. It goes actually before [26:05] epoch but see what it returns. Very [26:08] interesting thing. Okay. Then what is [26:09] the third and fourth thing? Let's do the [26:11] third and fourth. Third one is with date [26:13] string. You can create a date like new [26:15] date and then pass a date string like [26:18] this. This this particular format is [26:20] called ISO format. It is Y Y Y Y Y Y Y Y [26:22] Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y [26:22] Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y [26:22] Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y [26:22] Y Y Y Y Y Y Y Y Y Y Y Y Y Y and then you [26:23] have your mm and then the DD. Y Y Y Y Y [26:26] Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y [26:26] Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y [26:26] Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y is [26:27] nothing but the year then month and the [26:28] date. You can also pass the date string [26:31] in this format. When you pass in this [26:33] format which has Z 1 Z or Z at the end, [26:36] it means it is in the UTC time. Okay. Or [26:40] you can also pass it in a human readable [26:42] format like this January 15, 2024. So [26:46] you can use date string as an argument [26:48] to this date constructor and then you [26:51] can get the date back. However, you have [26:53] to use it with certain care right. So [26:56] what are the problems? Let's take an [26:57] example. Let's take a date like this. [27:00] Const date only equals to new date of [27:02] one ISO date. Okay great. Now the [27:04] problem with this is this new date. If [27:07] you pass an ISO date like this, it [27:09] treats this particular string as UTC [27:12] midnight. Now if your user's time zone [27:15] is behind UTC, behind UTC means UTC [27:18] minus something. Let's say Americans [27:20] which is UTC minus something. Now this [27:22] will display as the previous date. Now [27:24] if you use a date string like this [27:26] without the time, it may give you wrong [27:28] representation of the date depending on [27:30] your client's time zone. Now how to fix [27:33] it? To fix it, always append the time [27:36] and the time zone with it. So the [27:38] unambiguous way of doing this would be [27:41] like this. same date but I have appended [27:44] t 000000 plus the UTC time. If you do [27:48] that then things will be taken care [27:50] properly based on the local time and the [27:53] time zone. These are tiny things but you [27:55] have to remember and that is how you [27:57] won't be falling in the trap of making [27:59] mistakes while creating the date. Third [28:01] way is done. Now what is the fourth way? [28:03] The fourth way is using the year, month [28:05] and day as arguments. If you know that [28:07] which year, which month and which day, [28:09] you can use them as an argument and you [28:11] can create it. But here there are [28:13] certain mental load. For example, month [28:16] starts with a index. It means January is [28:19] zero, December is 11th. This is the [28:21] month index. So you have to know the [28:22] month index, day index and all this [28:24] thing. And you have to pass those index [28:26] not the actual name to construct the [28:28] date. For example, if I want January [28:31] 15th, 2024, I'll be passing 2024 the [28:34] actual year. January is zero because the [28:37] first month starts with zero and then [28:39] the date is 15. Month index is something [28:41] that you have to remember it starts with [28:43] zero. What if you need something like [28:44] this March 20th 2024 at 3:30 45 seconds [28:50] P.M. If you need something like this but [28:53] you are asked to create the date object [28:55] instance using this particular [28:57] methodology where you can pass the year, [28:59] month and day. How are you going to do [29:02] this? It's bit tedious but for our [29:05] learning sake say we'll say as detailed [29:08] date equals to new date. First you pass [29:11] 2024 which is year then you pass the [29:15] month month index of March is 0 is [29:17] January 1 is February 2 is March so two [29:20] then you pass 20 as the date then you [29:23] pass 15 means 3 p.m. 12 + 3 3 p.m. Then [29:28] you pass 30 and then you pass 45. Oh my [29:31] god, this is too much. Now a tricky [29:33] question for you. What does overflow [29:35] going to log? If I do console.log of [29:39] overflow with the variable name itself, [29:41] I have indicated it. This is going to be [29:43] 1st December 2024 or something else. [29:46] Remember the month index starts with [29:48] zero. That means January is zero. So [29:50] whenever you are giving like 12, 13, it [29:53] overflows to the next year [29:54] automatically. So this is going to be [29:56] January 1st 2025 because till 11th it [29:59] was in 2024 December. The moment it [30:02] become 12 it automatically overflows to [30:05] next year which is the first month [30:06] January. So it will be January 1st 2025. [30:09] So sometime you might be tricked in [30:11] interviews with questions like this. Be [30:13] prepared. JavaScript's date object [30:15] provides a bunch of getters and the [30:16] setters methods. First let's talk about [30:18] the getter methods. And in getter [30:20] methods also there are two types of [30:21] methods. One is for local time, another [30:24] is for the UTC time. Local getters [30:26] return the value in user's local time [30:28] zone and the UTC getters return the [30:31] value in the UTC. Always you need to [30:33] know which one you need. Let us first [30:36] get accustomed to all this methods. [30:38] First let us create a date object [30:40] instance. So I'm creating a date object [30:42] instance by passing this string value. [30:44] Now with this you can know like what [30:46] exactly it can represent, right? It [30:48] represents 15th of January 2024 at 3:00 [30:52] a.m. and the Z means it's in UTC. Okay, [30:56] so it's 3:00 a.m. UTC. Now let's talk [30:59] about the local getter methods. This [31:02] means based on machines time zone. Fair [31:05] enough. Now these are the methods you [31:07] can do. Date do.get full year is going [31:10] to give you the full year representation [31:13] which is like 2024 in this case. [31:15] date.get month is going to return the [31:17] month's index. It will return zero [31:19] because this is where we are talking [31:21] about the January month and zero means [31:23] January, 11th means December. We have [31:25] learned about that. This is going to [31:27] return the day of month between 1 to 31. [31:30] Okay. So this is going to return me 15. [31:34] Day dot get day. This is get date and [31:37] the next one is get day. Date dot get [31:39] day. It's going to return the day of the [31:41] week. Zero starts with Sunday and six is [31:44] Saturday. Okay, this is index you have [31:46] to remember. Get hours is going to [31:48] return the hours from between 0 to 23. [31:50] But get minutes is going to return the [31:52] minutes between 0 to 59. Get seconds [31:55] going to return the seconds between 0 to [31:57] 59. These are very important the [31:59] starting index. Okay, for day of the [32:01] week start index is zero. Hours, minute, [32:04] seconds, all start index is zero. Month [32:06] start index is zero. These are the [32:07] things you have to keep in mind. Then [32:09] dot get milliseconds is of course the [32:10] milliseconds between 0 to 9999 and [32:13] date.get time we have learned about that [32:15] milliseconds since epoch. This is one [32:17] thing we learned in the beginning [32:18] itself. All these methods are going to [32:20] give you information based on your [32:22] machine's local time. While local [32:24] getters are based on machine time zone [32:26] the UTC getters are not bound to any [32:29] time zone. These are time zone [32:30] independent. Exactly the same methods [32:32] like get full year you will do get UTC [32:35] full year. get month you will do get UTC [32:38] month get UTC date just put UTC in the [32:41] capital letters that's what the UTC [32:43] version of the method so it's going to [32:45] return the year in UTC going to return [32:47] month is UTC again these rules are same [32:49] a zero index day of the month day of the [32:51] week etc so we have learned there are [32:53] two varieties of method now this [32:54] information are there everywhere is [32:56] there in the MDN documents or any other [32:58] content but how is it going to impact [33:00] you that's what the main question let's [33:02] take an example to understand the impact [33:04] let's consider this scale the scale L is [33:06] like this UTC we know it is 0 0.00 0 0 [33:09] so anywhere we go left it is minus so at [33:11] this point this is UTC minus1 here UTC [33:14] -2 minus 3 and so on and the right side [33:16] it is UTC + 1 UTC + 2 and UTC + 3 UTC + [33:20] 5 and so on now let's take a country USA [33:24] let's take a city New York and New York [33:27] is at UTC minus 5 so let me circle this [33:31] for you so we are at UTC minus 5 now in [33:36] New York this is UTC minus 5. Let's see [33:39] a time at UTC. What it will be at the [33:43] new year at UTC minus 5. So a time that [33:46] will take as 3:00 a.m. for now. Okay. [33:48] Let's take a time called 3:00 a.m. at [33:51] UTC. What it will be the time in New [33:53] York. 3:00 a.m. 1 hour pass. It is 2:00 [33:56] a.m. here. It is 1:00 a.m. here. It is [33:59] midnight 12 over here. It is 11:00 p.m. [34:02] over here. And it is 10:00 p.m. over [34:05] here. Right? So 3:00 a.m. over here is [34:09] 1000 p.m. Correct? If I also add the [34:11] date, if it is like 11th Jan 2026 3:00 [34:17] a.m. at UTC, it means in UTC minus 5, it [34:22] is going to be 10 p.m. [34:26] But on the previous day, which is like [34:29] 10th Jan, you getting the point? So the [34:32] current moment if it is 3:00 a.m. at UTC [34:36] this is going to be that that particular [34:37] moment will be 1000 p.m. previous night [34:41] at New York which is at UTC minus 5 [34:44] correct this is how the scale [34:45] representation is very clear again [34:47] telling for anyone getting confused at [34:49] UTC 3:00 a.m. means over here it is 2 [34:52] a.m. minus 1 over here is 1:00 a.m. Over [34:55] here is if we go back 1 hour from 1:00 [34:57] a.m. it means 12 a.m. midnight. Then if [35:01] I go one more hour, it is 11 p.m. If I [35:04] go one more hour, it is 10 p.m. Right? [35:06] So that's how the scale works. Now why [35:08] all this story? Now if you do date dot [35:11] get UTC hours, which is supposed to give [35:14] us the hours in UTC, what will you get? [35:17] You will get three. So this is going to [35:19] return you three. But if you do date [35:22] hours, this is the hour that is in the [35:24] [clears throat] local time. So being in [35:26] New York, if you execute date hours, it [35:29] is going to give you 22, which is [35:32] nothing but the 10 p.m. So this is going [35:34] to return you 22. 22 means 10 p.m. [35:37] Correct? So you're seeing the [35:38] difference. When you need the UTC hours [35:41] being in any location on the globe, you [35:44] will go forget UTC hours. But if you [35:47] need the local hours for that particular [35:50] place from where you are running this [35:52] application, you will go for simply get [35:55] hours. This is just an example. [35:56] Similarly, if you do dot get UTC date, [35:59] what you are going to get? You are going [36:00] to get 11 because it is running on 11th [36:03] Jan. But if you do date, you will get [36:05] local date. You will get 10. That's the [36:07] difference. These are the confusions. [36:09] You write the method, you know, to [36:11] implement something in your code. But it [36:13] all depends where exactly that program [36:16] is running, which time zone it is [36:17] running, what kind of method you have [36:19] used. These are the small nitty-gritty [36:21] guys. That's what come back as a big [36:23] thing in production. So please [36:25] understand these things taking your time [36:27] even if this video is longer spend time [36:30] pause it understand what I'm teaching [36:33] practice it by yourself try to run it by [36:35] yourself sketch like this I'm sure that [36:37] these things will be imprinted in your [36:39] mind and brain very very quickly so [36:41] that's all about the getters local time [36:43] getters and the UTC time getters now we [36:46] are going to learn about setters just as [36:48] there are getter methods there are [36:50] setter methods as well and just like [36:52] getters setters also come with two [36:54] varieties. One is for the local and [36:55] other is for the UTC. One important [36:57] thing though, setters mutate the date [37:01] object in place. What does it mean? It [37:04] means whenever you're using any of the [37:05] setter methods is going to change the [37:08] actual date object and they do not [37:11] return a new date. This is very very [37:13] important because some bugs come because [37:15] of that. Once you use a setter method on [37:17] a date, you might expect that this is [37:19] going to return you a new date. No, it [37:21] is going to mutate the existing date. I [37:23] have a date now which I have initialized [37:25] with the ISO format date. You can see [37:27] over here and if I do a date dot2 ISO [37:29] string is going to return me the exactly [37:31] same string. Right now after this if you [37:33] just do date dot set full year and do [37:37] 2025 you had a get full year to get this [37:39] 2024. Right? Now if you do dot set full [37:42] year 2025 what it is going to do? It is [37:44] going to change this exact date by [37:47] making this 2024 to 2025. Okay. So [37:51] remember this. Here is the list of [37:52] setter methods. Exactly the opposite of [37:54] get month starts from zero index. So 0 1 [37:57] 2 3 4 5 means June date set the date to [38:01] 20th date. 8 hours 18 means it is 6 p.m. [38:04] in the local because there is no UTC [38:06] over here. So like that this setter [38:09] methods will go and there are equivalent [38:12] UTC setters. So what are the different [38:14] UTC setter methods are available? You [38:16] have set UTC full year, set UTC month, [38:19] set UTC date, set UTC hours. Right? So [38:22] these are the things available as a [38:23] setter methods. Again and again I'm [38:25] saying please avoid mutation. Let me [38:27] write it over here so that you remember [38:29] when you see this class code later. [38:32] Avoid mutation. [38:34] Always always clone your date object. [38:39] Please guys remember this. Let's take an [38:40] example of this so that you remember it [38:43] for the longer time. Let's say we have a [38:44] function. What this function does this [38:47] function add days that means you take [38:49] today's date and date it add a number of [38:53] days to this right let's say original is [38:56] 2024 15th of January now what will [38:59] happen if I do this in the next line add [39:01] days I have this original date and I [39:04] pass the number of days to add is 7 [39:07] let's take this in a variable const [39:09] called future [39:11] okay now can you tell me what will be [39:13] the output of this to console log if I [39:15] do original.2 date string future.2 two [39:18] day string what will be the output what [39:20] two date string returns if it is 2024 [39:23] 15th January it will return Jan 15 [39:26] something like this representation Jan [39:28] 15 so if this is what two date string [39:31] returns what will be original string [39:33] what will be future dot2day string you [39:35] might say that okay original2 string [39:38] which is like this this is going to [39:40] return Jan 15 now we have added seven [39:42] more days over here so this is going to [39:44] return Jan 22nd 15 + 7 is 22nd No, you [39:48] will be making a mistake if you assume [39:50] that as we have modified the same date [39:53] here with date dot set date method we [39:56] have modified the original reference [39:58] already. So both original and future is [40:01] now modified to Jan 22nd. This is the [40:04] mistake. This is where you have mutated [40:07] the date by mistake at the first time [40:09] itself. So please don't do this. So how [40:11] can you now change this add days [40:13] function to save from it? Of course, [40:16] first and foremost thing is create a new [40:20] date instance from this date and then [40:23] use this guy to set the date and then [40:26] you can actually return this new guy new [40:29] instance. That's all right. So if you [40:31] now call this then this is going to be [40:34] Jan 15 and this is going to be Jan 22nd [40:37] and it is now not mutated. Okay, I hope [40:40] you understand that. So whenever you are [40:42] dealing with date you have to ensure [40:45] that this mutation never happens because [40:46] if the mutation happens it might create [40:49] a complete mess with your date and time. [40:51] Let us get familiar with few more things [40:53] around getters and setters. Okay the one [40:56] of the main problem that comes from the [40:58] zero index months that zero means [41:00] January 11 means December. We tend to [41:02] make many common mistakes. For example [41:04] take this date is Christmas right? 25th [41:07] of December. Now one of the common [41:08] mistake that happens is when we do [41:11] console.log date.getmon most of the time [41:14] developers tends to feel that it is [41:15] going to return 12 but this is going to [41:17] return 11 because month's index starts [41:20] from zero which is January 11th is [41:22] December. So the correct way to always [41:24] deal with if you want 12 always add one. [41:28] So if you want 12 to be displayed [41:30] anywhere you should always do + one to [41:33] this then only your display value will [41:35] be 12. though the API has returned you [41:38] 11. Please remember that. One principle [41:39] that you can follow, you can always [41:41] create an array of months like January, [41:44] February, March, array in JavaScript is [41:47] also zero index. It means the index [41:49] starts with zero. So month of zero is [41:51] going to return you January. Now let's [41:52] say you are in the month of December. So [41:55] date.get month is going to return what? [41:57] 11. And pass date.get month. And imagine [42:00] you are in December now. So date.get [42:02] month is going to return 11. So it [42:04] become months of 11 over here. 11th [42:07] index is nothing but the December [42:09] because array starts with a zero index 0 [42:11] 1 2 3 4. If you go like this it is [42:14] December. So this is going to return you [42:16] December. So this is one way you can [42:18] actually manage the months in your code. [42:20] Same thing happen for the days of week [42:22] also because that's also starts with [42:24] zero index. Zero means Sunday, one means [42:26] Monday and so on. So similar kind of [42:28] thing you can apply over there. Let me [42:29] talk about one more goes. All these [42:31] things are from my personal experiences. [42:33] So sharing as much as I can. Let's [42:35] imagine you are building a function for [42:38] today's components. Okay. And this is [42:40] your function. Now can you tell me what [42:41] is the problem with this function? [42:43] Simple one. Get today's component [42:45] instantiating a new date. So the got a [42:47] new date instance. And then now dot get [42:50] full year the current moments full year [42:52] current moments get month plus one we [42:54] did and then the current get date and we [42:57] are having an object. This object we are [42:58] creating. What is the problem with this [43:00] one? As we understood before all the get [43:03] methods having two variety one is the [43:04] UTC and is the local. So this get full [43:07] year get month get date as it doesn't [43:09] have that UTC in its name is going to [43:12] return all this value in your machine's [43:14] local time zone value. Now imagine this [43:17] get today component whatever the return [43:19] value you are directly saving into a [43:21] database through an API. So if you're in [43:24] New York from there if you are client [43:26] side executing this one you end up [43:28] saving this object in your machines [43:31] which are which is in New York that [43:33] particular machines year month day that [43:36] values with those values but if you [43:39] remember this diagram in database we are [43:41] supposed to store everything in UTC [43:44] right in epoch format everything is in [43:46] UTC we are not supposed to store any of [43:49] the local time representation right [43:52] that's the exact thing that's the exact [43:54] mistake that you are doing here by using [43:56] the get full year get month get date if [43:59] you have such use case where you have to [44:00] store this to the database not for the [44:02] display purpose always always use get [44:05] UTC full year get UTC month get UTC date [44:09] understanding why you have to do UTC [44:11] versus local and when and where you have [44:13] to do it this is how you have to keep [44:14] things in your mind and once you know [44:16] these fundamentals nobody's going to [44:18] stop you can write date and time code [44:21] like a boss another idea where you got [44:23] to be a bit careful when you want to [44:25] parse or validate dates. Okay, for [44:28] example, of course, this is going to [44:29] give you exception because this is not a [44:31] valid date and date objects handles [44:32] that. So once you do console.log of this [44:35] bat is going to say is invalid date. [44:37] Question for you, what is this line [44:38] number 123 going to print? Console.log [44:41] is nan bat is not a number bad. What is [44:44] going to give? Of course, it's going to [44:46] give true, right? Because it's an [44:47] invalid date and it's not a number. Is [44:49] going to give you a true. Now the [44:51] question is how can you effectively [44:54] check if a date is valid date or not. [44:56] One way that you can check is function [44:59] is valid date. Let's take a date and you [45:02] can return if the date instance of the [45:06] date object. This is one. And if it is [45:11] not of is not a number the check that we [45:15] have just now did we can do like date [45:17] do.get time right? So if dead dot get [45:21] time which always returns that [45:22] milliseconds in UTC time and that is [45:24] always going to be a number if it is a [45:27] number not of is not a number is a [45:29] number right so if it is a number and if [45:32] it is the instance of a date then you [45:34] can say that is a valid date now as you [45:36] have this is valid method you can make [45:38] use of this is valid method to make the [45:40] date parsing even more stronger [45:42] especially the cases where your date is [45:45] passed with a string representation and [45:47] you have to parse that. So you can write [45:49] a method like this. See this is a safe [45:50] parse method which take a string date [45:53] string. Basically first you check [45:54] whether the date string is there or not. [45:55] If it is not there you can return null. [45:57] Then you create a new date. We know this [45:59] is one of the ways you can create a [46:00] date. Now once you get the date object [46:02] you are passing through this is valid [46:04] date. If it is a valid date you return [46:06] the date otherwise return a null. So [46:08] having a utility function like that is [46:10] always good to handle the parsing of [46:13] your date string. So this is something [46:15] that I have been using and I'm just [46:17] teaching you some of the good parts of [46:19] handling date the correct way because [46:21] dates are just numbers underneath. So [46:24] date arithmetics will be just about [46:26] adding and subtracting the milliseconds. [46:28] Right? When you are dealing with dates [46:30] and then you want to change the date by [46:32] adding subtracting the milliseconds. It [46:34] means that you want to go to a [46:35] particular seconds or minutes or hour or [46:38] a day. Right? So what I do generally I [46:40] create an object like this. This is my [46:42] millisecond object. I define a 1 second [46:45] means it is like 1,000 milliseconds. I [46:47] define 1 minute means you know 1,000 [46:49] millconds multiplied by 60 so as hour [46:52] and so as day. So it means anywhere in [46:54] your code if you want to do some [46:56] arithmetic operation like subtraction or [46:58] addition for a day you can do ms dot day [47:02] same for hour ms dot hour ms dot minute [47:04] and ms dot second. Let us first create a [47:06] date let's say con today equals to new [47:08] date. Now how can you move it to in 7 [47:12] days like from today to 7 days. How can [47:14] you move it? You can add 7 days. I [47:17] already have day. You can see over here. [47:19] How can you do 7 days? MS dot day [47:22] multiplied by 7 is going to be 7 days. [47:25] Now I have today. So if I do today do [47:28] get time, I'm going to get the [47:30] millisecond representation of today. If [47:33] I add 7 days to it, this total [47:35] milliseconds is going to take me to the [47:37] 7th day. So I can now write the logic [47:40] like in 7 days equals to new date today [47:43] dot get time plus 7 into ms dot day. Got [47:46] it? If I have to do yesterday simple [47:48] today do get time minus 1 into ms dot [47:52] day I go one day back right very simple. [47:55] Now you can always create a utility [47:56] function or utility method like add days [47:59] which can take a date take the offset [48:01] days that you want to go and then you [48:03] just pass them. Remember here I didn't [48:05] mutate this date. I have created a new [48:07] instance of the date. This is what we [48:09] have learned not to mutate because you [48:11] are going to use the set methods. Okay. [48:13] So this is about adding and subtracting [48:15] the time. How can we calculate [48:17] difference between dates? One is 1st [48:19] January 2024. Another is 31st of [48:21] December 2024. How can you do a [48:24] difference between them? Okay, we can do [48:26] something like const milliseconds equals [48:29] to end minus start. What it is going to [48:32] give me? It is going to give me the [48:33] millisecond difference between these two [48:35] dates. If I calculate and print this [48:37] diff ms on console.log, it will be [48:40] something like this number. This big [48:41] number. Now once you get this big number [48:43] in millisecond, you can write your own [48:46] logic to convert into useful units. So [48:49] for example, if you want to convert this [48:51] big number, the difference number in [48:54] difference in days. Then how will you do [48:56] the number that you have? You can divide [48:59] by what? If it differs by days means in [49:02] 1 day there are 24 hours in 1 hour there [49:05] are 60 minutes in 1 minute there are 60 [49:07] seconds and in 1 second there are [49:09] thousand millconds right so you will be [49:11] writing a logic like taking this t ms [49:15] divided by 24 hours in a day 60 minutes [49:18] in an hour into 60 seconds in a minute [49:21] into 1,000 milliseconds in a second if [49:23] you do that you get the this difference [49:26] means there are how many days between [49:28] this 1st January 2024 to 31st of [49:31] December 2024. Similarly, if you want [49:34] the difference in weeks, what you'll be [49:35] doing? You get the difference of days, [49:37] divide by 7 difference in week. So, this [49:39] is how you go about finding differences. [49:42] Right? Now, you can write a method which [49:44] basically can return you all these [49:47] different differences in different kind [49:49] of units like days, weeks, hour, [49:51] minutes, whatever the ways that you [49:53] want. Now, here is a task for you guys. [49:55] Can you create an H calculator with all [49:59] this learning that we have? Okay, don't [50:01] take uh the help of AI in the beginning. [50:03] Okay, try to write and then whatever the [50:05] code you write, give it to any LLM and [50:07] ask the LLM whether the logic you have [50:10] written is good enough or there are any [50:12] improvements required or not. And [50:13] whatever you get back from LLM, learn [50:16] from that like what are the improvements [50:17] required. But if you have written a [50:18] logic which doesn't need any further [50:20] improvements, great. Also you can come [50:22] to our discord and share about your [50:24] logic. Would love to look into it. So [50:26] what we are going to do? You are going [50:28] to create a calculate age function. If I [50:32] pass any birthday for example say [50:34] 199065. [50:37] So it means that 5th June 1990. If I [50:40] pass that you have to return what is the [50:43] age whether age is 33 34 whatever the [50:45] age that you have to return. So [50:46] calculate age takes a birthday a date [50:48] and it will return what is the age of [50:51] that person based on this birthday. Can [50:53] you write the function for this? So this [50:54] is your task. Now let us get into one of [50:57] the problematic area in managing date [50:59] and time which is leap year. But before [51:01] we talk about leap year, let's talk [51:02] about a concept called solar year. A [51:05] solar year is the time that it takes [51:08] earth to orbit the sun. So you have sun [51:11] in the middle and then there is earth. [51:13] So is the solar year is the time that [51:16] takes earth to orbit the sun and the [51:19] solar year value is approximately [51:22] 365.2425 [51:24] days. This is not exactly 365 okay [51:27] little more than that.2425 days. Now to [51:30] keep our calendar aligned with earth's [51:33] orbit we periodically add one extra day [51:36] and that extra day is nothing but the f [51:39] 29th. This day is called as lip day and [51:43] the year this 5th 29th fall into we call [51:46] it as leap year. Now this might sounds [51:48] very straightforward that okay if there [51:50] is a February 29th in a year we'll call [51:53] it as leap year. But the calculation for [51:55] leap year is not that straightforward. [51:57] Let me write the pseudo code or or [51:59] rather the algorithm for it. Okay. So a [52:01] year will be a leap year if there are [52:07] two or three conditions. What is the [52:08] first condition? Year is divisible by [52:13] four. If you can divide the year by [52:15] four, year is always a number like 1900, [52:18] 2024, 2026. If you can divide it by [52:21] four, then it is going to be a leap [52:23] year. This much we know but there are [52:25] few other conditions. The conditions [52:27] second is except it is also divisible by [52:34] 100. If you can divide the year by 100 [52:37] even though it can be divided by four it [52:39] is not a liar. Okay. So this is where [52:41] the complexity comes and unless it is [52:45] also divisible [52:49] by 400. This is what makes it lipier [52:52] again. Okay let me make you understand [52:54] with certain example. How about 2024? [52:56] 2024 is a lipier because it can be [52:58] divided by four. How about 1900? 1900 is [53:02] not a lipier because it can be divided [53:04] by 100 but not by 400. How about 2,00? [53:07] 2,000 was a lipier because it can be [53:09] divided by four. It is divided by 100 [53:12] but still it can be divided by 400 also. [53:15] So this is the rule. The rule is it can [53:17] be divided by four except it can also be [53:21] divided by 100 unless it can be divided [53:24] by 400. So this is exactly the algorithm [53:28] to know if a year is lipier. So coming [53:31] to JavaScript, how are you going to [53:32] write a logic to find out if a year is a [53:35] lip year or not? Let us do that. Lip [53:37] year. So function [53:40] is lip year. Let's take the year that [53:44] we'll be passing over here. So return [53:46] true or false. So for that purpose if [53:49] the year is divisible by four and how do [53:55] we know if it return zero with the mod? [53:57] Say divisible by four. and year [54:00] divisible [54:03] by 100. This is the case of not because [54:06] except or year divisible by 400 and this [54:12] is the case that we have to satisfy. So [54:14] the first case is this and the second [54:18] case is this. I think we can omit this [54:20] parenthesis. Yeah. So if a year is [54:23] divisible by four and the year is not [54:26] divisible by 100 or the year is [54:29] divisible by 400 in this case we can [54:32] call a year is a leap year. Now we can [54:35] run this. Okay I'm correcting the [54:36] spelling of the function. Okay now we [54:38] can run this with different test cases. [54:40] If we pass 2024 yeah it is true because [54:43] it's divided by four. This is where it [54:45] will be true. 1900 false divide by 100 [54:49] but not by 400. 2002 divide by 400 2023 [54:54] false because it is not divided by four [54:56] itself. When we talking about date and [54:58] time you have to deal with one more [54:59] beast and that beast is DST daylight [55:02] saving time. What is DST or the daylight [55:05] saving time? So daylight saving time is [55:08] a practice that some of the countries [55:10] follows. For example, the US follows [55:12] some part or I'll say the maximum part [55:14] of Europe follows but again many of the [55:16] other countries like India, Japan, they [55:18] don't follow it. It's a practice of [55:21] advancing your clock by 1 hour during [55:24] the summer months so that darkness falls [55:27] later in the day and this is the whole [55:29] idea of shifting by 1 hour daylight from [55:33] the morning and it is when most of the [55:34] people are asleep so that the evening [55:36] more time can be make use of right [55:38] that's the whole purpose of it now as [55:41] all the countries are not really observe [55:44] BST together it's very hard that for a [55:46] particular go you have to keep in mind [55:48] that you have to handle this DST. Now [55:50] there are few things that you need to [55:52] understand that this clock get advanced. [55:54] Now the clock also comes back. It is not [55:56] like once advanced it will always run in [55:58] the advanced mode. No. So in a year when [56:00] the summer start in a particular month [56:02] it gets advanced and when a particular [56:04] month comes again it gets again reseted. [56:06] So how this happens? For example, in the [56:09] US, if we see right now, you know, when [56:11] we I'm making this video in the month of [56:13] March, DST actually DST starts [56:18] on the I think second Sunday in March. [56:22] So what happened when DST starts at this [56:24] time clock spring forward 1 hour at 2:00 [56:27] a.m. Okay, at 2:00 a.m. Remember this, [56:30] it just spring forward at 2:00 a.m. [56:33] Skipping to 3:00 a.m. This is when the [56:35] advancement happened. And when it ends [56:38] so it ends in November precisely the [56:42] first Sunday of November [56:44] and very interesting on this day how it [56:48] get reset clock falls back at 2:00 a.m. [56:51] repeating this is very interesting [56:53] repeating [56:54] 1 a.m. to 1.59 [56:58] a.m. twice. So when DST starts on the [57:02] second Sunday in March, 2:00 a.m. will [57:04] be skipped to 3:00 a.m. get advanced and [57:07] to readjust in November on the first [57:09] Sunday of November, it repeats 1:00 a.m. [57:12] to 159 twice. So that it gets [57:15] readjusted. Okay. So this is how the GST [57:17] works. Now this can create nightmare. If [57:20] you're not aware of this logic, if [57:22] you're not aware, there is something [57:23] called DST exist. So at times you might [57:26] have to keep this into account to check [57:28] whether the time range when your [57:31] operation is happening is DST applied or [57:34] not. If DST is applied you will do [57:36] certain things in certain way. If DST is [57:38] not applied you will do certain things [57:39] in a different way. So I'll tell you how [57:41] JavaScript handles this. Let's talk [57:42] about DST advancement. When DST start, [57:46] right? So DST starts like by skipping [57:49] 2:00 a.m. to 3:00 a.m. on 2nd Sunday of [57:52] March. Let's take a date hypothetically. [57:54] Let's take a date say 10th March. 10th [57:56] March when say DST starts. Okay. So when [57:59] I create a new date passing all the [58:01] year, month, date, time, everything like [58:04] this, you know this is one of the ways [58:06] we can create date. This gives me March [58:08] 10, 2:30 a.m. Correct. Now if I just run [58:12] this code in the US eastern time zone [58:15] this time on this date doesn't exist [58:18] because when DST starts 2 a.m. skips to [58:21] 3:00 a.m. Then where is the 2:30 coming [58:23] from? Okay. So JavaScript will [58:26] automatically shift it forward to 3:30 [58:29] a.m. It will shift it forward. So for [58:31] example if you take this in a variable [58:33] say const skip equals to new date this [58:37] and if you do skip dot get hours you [58:41] will not get two you will get three [58:43] javascript will take care of this shift [58:45] forward so shifting is good please [58:47] remember this let's talk about the [58:49] falling back on November right and it [58:52] happens between 1:00 a.m. to 1:59 a.m. [58:55] So 1:00 a.m. to 1:59 a.m. on that [58:58] particular day of November, the first [59:00] Sunday of November happens twice. This [59:02] is how the DST works on those time [59:04] zones. But unfortunately, JavaScript [59:07] cannot distinguish between these two [59:12] 1:30 a.m. So, it picks the standard [59:16] time. Nondst time is what is going to [59:18] pick. So, this is something that you [59:19] need to remember when you are dealing [59:21] with DST for any specific region using [59:24] JavaScript. Now you can go ahead and [59:26] check how to determine if it is DST or [59:28] not. Right? You can just do any LLM [59:31] search, any Google search, anything of [59:33] this particular thing is like how to [59:35] detect DST. You will realize the logic [59:37] for that you are going to understand [59:39] without any difficulty now because you [59:42] understand all the basic methods that [59:45] JavaScript provides you and on top of [59:47] that using those methods you can do [59:49] multiple things. For example, one of the [59:52] thing is like you can check whether it's [59:53] a DST or not. Check out this method. Do [59:56] some research about it. So before we end [59:58] this part, let's revise some crucial [60:00] points. First point we spoke, always [60:03] store as UTC or time stamp, right? Never [60:06] the local time. Second, compare using [60:09] time stamp not by the actual date value. [60:11] Then always parse ISO 8601 string, the [60:15] one with the Z or the Z, right? Because [60:17] that's the UTC format. Never ever muted [60:20] the date directly. Always create an [60:22] instance and then mute. Months are zero [60:24] index. January is zero. December is 11. [60:28] Always add one for display. Right. Add [60:30] days with set date not the raw [60:32] millisecond. This is DST safe. And the [60:35] last one use UTC getters on the server [60:39] not the actual getters because that [60:41] gives you local time. So hey that's all [60:43] about part one. In part one we have [60:45] covered a lot of things. We understood [60:47] why date and time is really complicated. [60:50] The history behind it, how to take care [60:53] of things, how to create dates, how to [60:55] do the arithmetic operations, the [60:57] gators, setters, differences, then the [61:00] leap years, then the DSTs, the good [61:02] practices, some of the gotchas. There [61:04] are a lot of stuff that we have covered. [61:06] These are the foundations guys. If you [61:07] know this foundation, you are going to [61:10] do great with date and time in [61:11] JavaScript. My request would be please [61:14] practice some of these things, right? [61:15] because I didn't want to make this video [61:17] for like 3 four hours with so much of [61:19] examples and practice because those [61:21] examples and practice are available on [61:23] internet. You just need to remember [61:25] these fundamentals that we have ran [61:27] through together. Coming in the part [61:29] two, we are going to make it in the [61:31] professional way. That is where you will [61:33] be learning how to do things like you [61:35] know 7 days ago, 3 days after all this [61:37] kind of debt calculation. You don't need [61:39] any library is provided by JavaScript. [61:42] There is an API called INTL. Using that [61:45] we'll be doing lot of stuff and I'm also [61:47] going to get you introduced to the new [61:49] temporal API. So if you found this video [61:52] till now the part one, drop a like and [61:54] subscribe. Today I want to welcome you [61:56] to part two. But if you haven't done the [61:59] part one, my high recommendation would [62:00] be to finish that and then come to part [62:02] two because we are going to build a few [62:05] things on top of whatever you learned in [62:07] part one. In part two today we are going [62:09] to talk about JavaScript's one of the [62:11] most underappreciated factor that is [62:14] INTL API. Believe me it's an underrated [62:17] stuff that JavaScript has. Many of the [62:19] developers don't use it because they are [62:22] not very much aware of it and they end [62:24] up using some external libraries that [62:26] library go out of date. They have to [62:27] manage migrate and all these things they [62:30] need to do. Instead of that JavaScript [62:32] natively supports you everything that [62:34] you need to do with date and time [62:36] format. Yes, it's including time zone, [62:39] including locals, including other [62:41] geographics. Today, in this video, we [62:43] are going to master all of this. Trust [62:45] me, by the end of this video, you will [62:47] be able to format any date and time in [62:49] JavaScript in any language in any local [62:52] without any external libraries. Let's [62:54] go. The Intel API, short for [62:56] internationalization API, is a built-in [62:59] JavaScript namespace that provides [63:02] language sensitive operation. By the [63:04] way, in lip is not just for dates. It's [63:07] for number formatting. It's for currency [63:09] formatting. It's for pluralization and [63:12] more. But for our series, we will limit [63:14] our discussion to date and time. We have [63:16] an in-depth documentation provided by [63:18] MDN on INL. You can always come take a [63:22] look into it. Go deep dive. However, in [63:24] this video, my objective is to pick the [63:27] one that will be heavily used. Pick the [63:30] one that you need in your daily life to [63:33] fix things, to format things with date [63:35] and time. So if you just focus on part [63:37] two, I think you will be able to get to [63:40] know most of it. If there are any [63:42] deltas, this documentation is always [63:44] there for you. Today's session, we're [63:45] going to code a lot. That's the reason [63:47] I've opened up my code editor and [63:49] running the browser side by side. So [63:51] that whenever I change some code, you [63:52] can see that immediately in the right [63:54] side browser step tool. Here's a simple [63:56] HTML through which I'm running this [63:58] index.js file and I'm going to code [64:01] everything inside this index.js file. [64:03] This initial console.log log you are [64:04] seeing like js intl API session is [64:07] already appearing over here proving that [64:09] whatever I'm going to code over here is [64:11] going to reflect one quick thing I have [64:13] just dstructured the log from the [64:15] console object so that I don't have to [64:17] write console.log log everywhere. I can [64:19] just write log. It's easy. Less typing. [64:21] All right. So, let's get started with [64:23] our Inel API. Before the Inel API ever [64:27] existed, formatting date and time for [64:30] the international users was a nightmare. [64:32] You have to think about it. You have to [64:34] manually look up how each country format [64:38] their dates and time. Then you build a [64:40] lookup table for translating the month [64:43] names, the right to left languages like [64:46] Arabic. manage different kind of [64:47] calendar systems. Think about it how how [64:49] how much difficult it is. It was an [64:52] enormous amount of work that every team [64:55] had to do from the scratch. I have spent [64:57] more than 20 years in software [64:59] engineering and development. I have done [65:01] it myself. I know how hard it was. Just [65:04] take a look into this different kind of [65:06] date and time format. For example, in [65:08] United States, you call out the date [65:11] formatting like this. First the month, [65:13] then the date and then the year. and it [65:15] is like 2:30 p.m. But when you go to UK, [65:18] it changed. The formatting now become dd [65:20] mm y and now it's a 24 hours clock. If [65:24] you go to Germany, instead of slash, it [65:26] become dot and you see it's in their [65:28] native language. If you go to Japan, the [65:31] formatting again change year comes in [65:33] the front. So for every countries, for [65:36] every local, every time zone, there [65:38] could be a possibility of different date [65:40] and time format. Now imagine that you [65:43] managing all these formats for [65:46] geographies locally in a code like a map [65:49] like a table like a JSON object keep [65:52] maintaining it it's a nightmare thank [65:54] god we have INL API today the INL API is [65:57] defined by the uni code what is CLDR clr [66:01] is the common local data repository like [66:05] a database which is world's largest [66:07] database for local aware formatting [66:10] rules this is where all different kind [66:12] of formatting rules will be stored. So [66:14] whenever you use INTL in JavaScript [66:17] whether it's on the browser or on the [66:19] NodeJS side the runtime consults this [66:22] particular database to produce the [66:24] correct output for any local under incl. [66:28] The primary method is datetime format. [66:30] Datetime format constructor takes two [66:33] arguments. The first one is the area of [66:35] locals or a single local. The second is [66:38] a configuration options. By the way, [66:40] both these arguments are completely [66:42] optional. You may or may not want to [66:45] pass them. But we will see a lot of [66:47] examples where passing the local and [66:49] passing the options are very very [66:50] powerful thing for you to convert a date [66:53] with a particular date and time format. [66:55] So let's take this new intl time format. [66:59] I'll copy it and paste it over here. I [67:01] don't need any of these arguments to [67:04] start with. Now what it returns? It [67:06] returns a formatter because we are doing [67:08] a date and time format. Right? So we can [67:11] do const formatter equals to new intel [67:15] date and time format. Once you get this [67:17] formatter on formatter you can invoke a [67:20] method called format to format the date [67:22] and time actuary. So what we can do we [67:24] can do fmt that's the formatter. We can [67:27] invoke a method called format and we can [67:30] pass any date to format. Let me put this [67:33] entire thing inside a lock because this [67:36] fmt dot format is going to return me the [67:39] formatted date. Okay, I have to do const [67:41] here spelling mistake. So I got this [67:43] particular date that I have passed over [67:45] here formatted in my current local. Fair [67:48] enough. Similar to this, I can just pass [67:51] date now which is the current moment of [67:54] time in the milliseconds. We have [67:56] learned that. So this is going to return [67:58] me the same thing because we're talking [67:59] about just the date. I can even pass any [68:02] milliseconds in date representation. You [68:04] can see I'm passing this particular [68:05] milliseconds which is going to give me [68:07] the date but in 2025. Okay. And if I [68:10] don't pass any date to the format [68:13] function then it is just going to format [68:15] the today's date. Okay. So all this [68:17] usage now you know of format. Once you [68:19] have a formatter from intlatime format [68:22] you can invoke the format function on [68:24] top of that or the method on top of that [68:26] and then can pass any date that you want [68:28] to format. Now this date time format I [68:31] have used without any local and any [68:34] options. Now let's see some example with [68:37] locals. So first get this new intlatime [68:41] format and pass the local enus. Let's [68:45] take this in a variable called US fmt [68:48] means US formatter. Similar to this let [68:51] us create UK formatter, German formatter [68:54] and Japanese formatter. Same thing just [68:56] pass the different local. Again locals [68:58] and the options both are optional. I am [69:01] just passing locals now so that I can [69:03] show you the advantage of it. Now let's [69:05] take a date. So in UTC today's date time [69:09] is 2:30. You can see that. Let's start [69:11] formatting. First we will use this US [69:14] formatter. Once we use the formatter now [69:17] you know we can invoke the method called [69:19] format. And over here we can pass the [69:21] date right. So we can pass this [69:23] particular date. You see over here in EN [69:26] US it is showing me date in this [69:28] particular format. All right. Just to [69:30] make it more clear I'm just adding the [69:32] string. So with US formatter I'm getting [69:34] the date formatted in this way. So [69:36] similarly if I try out all these [69:38] different other formatterers with UK [69:40] formatter UK formatter dot format pass [69:42] the same date. D formatter. Pass the [69:45] same date and see the log see the [69:47] differences. In US it is mm dd Y. In UK [69:52] it is dd mmm y. In DE it is dot like [69:56] dd.m m doty y. In Japanese it is y / m/d [70:05] completely different format. You don't [70:07] have to really remember which format [70:09] which local supports. You just pass the [70:12] local create your formatter. On top of [70:14] that call the format function pass your [70:16] date. It is going to return you the [70:18] formatted date for this local. how easy [70:20] it is. By the way, coding with me, [70:22] right? Don't just look what I am coding. [70:24] It's not going to be of any use. Please [70:26] open your favorite code editor or open [70:29] your browser, go to dev tools, go to the [70:31] console tab and start coding everything [70:33] that I'm coding. Pause the video [70:35] wherever you want, look into the things [70:37] that you're coding, what kind of output [70:38] it is giving, grasp it and then only [70:41] look into the next section. Okay? [70:42] Without you do hands-on, going through [70:45] any tutorials is of waste of time. All [70:48] right? Now the third part in the third [70:50] part we are going to learn about this [70:52] options. So when we do intlate time [70:55] format we can pass the locals. We have [70:57] seen that example. Now we'll be seeing [70:58] the example like what kind of options we [71:01] can pass. So first let us take a time. [71:03] The time we have taken again today's [71:05] time and then we will get the formatter. [71:08] Let's take it in a variable called dtmt [71:10] which is nothing but date formatter. Now [71:12] here two things we can pass. First we [71:14] can pass in US. What it is? It's a local [71:18] and if I just do log of dt fmt you know [71:23] it what it is going to give right it is [71:25] going to give me this date time format [71:26] object if I do dot format on top of that [71:29] because that's what I have to pass to [71:30] format the date now it is going to give [71:32] me the formatted date in US local now I [71:36] want to learn certain options let's say [71:40] that the option I am interested in right [71:42] now is how to style the date that I'm [71:45] getting from Here I can actually style [71:47] the date. Okay, how can I do date style? [71:50] I can pass a option called date style [71:53] and pass different kind of value for it. [71:55] For example, full. Now let's see what it [71:57] gives. It gives me the same date but [72:00] formatted into a full date format where [72:03] it says this day is Sunday completely [72:05] March 15, 2026. [72:08] Complete date in a elaborated full [72:10] format. There are other format for [72:12] example instead of full if you can just [72:14] go long. L ng if I do you see this going [72:17] to change it's going to change to March [72:18] 15 2026 now the full format was telling [72:21] Sunday Sunday gone now it's saying March [72:23] 15 2026 if I just do short instead of [72:26] all this now it is going to tell me 315 [72:29] 2026 the format that I was getting by [72:32] default so what does it mean where [72:34] exactly these options are very handy if [72:36] you want to get a very elaborated date [72:38] format formatted in a particular local [72:42] go for the full format then if you Don't [72:44] need that. Go for medium format. Go for [72:46] long format. Go for short format. Okay. [72:48] So I have given you the full over here. [72:51] I have showed you the long short. Please [72:53] try long, medium, short. Everything as [72:55] and when you're trying stuff. So this is [72:57] great. DT format worked. Now can I do [73:00] same thing for the time format? Yeah. [73:02] I'm just going to copy this guy. Okay. [73:04] For you. I'm just going to copy this [73:05] from here. And then I'm going to paste [73:08] it the same thing. Okay. It's going to [73:10] crash for some time. It's fine. And I am [73:12] going to change this variable name dtm [73:14] dt fmt to tm fmt means time format. [73:19] Okay. And instead of date style let me [73:21] just say time style. [73:25] And here I will pass tm fmt [73:30] dot format. Now do you see this output? [73:33] It's giving the time in the full format [73:36] fully formatted 80045 [73:40] p.m. with Indian standard time time zone [73:43] also exactly the similar way how we have [73:46] tried different other styles. For [73:47] example, if I go long, see the change [73:50] the IST has gone. Now it become GMT plus [73:53] 5:30. If I just do short, see the [73:55] change, it just become 8:00 p.m. You saw [73:57] that? So now based on whatever style you [74:00] need for your application, you can just [74:02] do it just by passing some of these [74:04] options. So please play around with it. [74:06] That's why I'm saying it is very very [74:08] useful. Now can we combine both of [74:10] these? Yes, we can combine. Let's do [74:11] that. Let's do con fmt same new intel. [74:15] Time format and here I'm going to pass [74:18] some options. What are the options I'm [74:20] going to pass? If I have to combine [74:21] them, I want for example style in short, [74:24] time style in short. So I will pass both [74:27] the formats like this and after that I [74:29] will just do log of [74:32] fmt dot format pass the date. Now you [74:36] will see a new output where date and [74:39] time both are formatted into the short [74:40] format. Oh you want date in full time in [74:43] short. Yeah why not make date is full [74:45] time is short. Yeah is full now time is [74:48] short. Oh you want this also in full? [74:50] Yeah let's do that. You see that this [74:52] also in full. This is one thing that you [74:54] do all full you know where you do mostly [74:57] for the logging whenever you want to log [74:59] something you generally go for [75:01] everything kind of full full this way [75:03] okay this formatting is done now can I [75:05] repeat this for other local yeah I can [75:07] do it do for D I've created a D [75:09] formatter same I intel dead time format [75:12] but the local I have passed DE for [75:14] janman and date style full time style [75:16] short I have used full and short and I'm [75:18] printing over here you see over here see [75:21] the difference the [75:22] Sunday here in English but over here in [75:25] that particular language right that's [75:27] the advantage see the march over here [75:29] and see how they call merch right can I [75:31] do the same thing with Japan oh yes I [75:33] have created now Japanese formatter [75:35] passing jp and make it like full and [75:38] short and when I log this by formatting [75:39] the date you see it's coming all in [75:41] Japanese and this is how you need it you [75:44] cannot represent a date and time in [75:46] English if you're serving a Chinese or [75:48] the Japanese user they may not be that [75:50] much accustomed with English language [75:52] always you should not be assuming that [75:54] rather it should be formatted into their [75:57] native into their local language that's [75:59] exactly we are doing here with date and [76:00] time formatting okay now let's see some [76:03] more practical examples so this far we [76:05] have learned that we can do intlat time [76:07] format can pass the local can pass the [76:09] options to format a date now this is [76:11] like bit verbose you have to do this inl [76:15] deadet time format every time to get a [76:17] formatter then you have to call a format [76:19] method on top of the formatter you have [76:21] to pass the date. Instead of doing all [76:23] this circus, you know what we can do? We [76:26] can write a single thing. For example, [76:28] we can write something like con fmt [76:31] equals to this is a function. It will [76:33] return a function. Pass the local and [76:36] then pass the options opts. Let's use an [76:40] arrow function over here. And what it [76:43] returns? It returns the new intl [76:46] dot datetime format. And then you pass [76:49] the same local same opts over here. On [76:54] top of that you call your format [76:56] function or the format method and pass [76:59] the date. Now this behaves like a [77:01] oneliner replacement of all those things [77:03] we were doing before isn't it? So fmt is [77:06] a function now because this is what we [77:09] have assigned a particular function. [77:11] It's an arrow function. This functions [77:13] return what? It returns the formatted [77:15] date for you altogether. is calling new [77:17] intel.et date time format passing the [77:20] same local same opts also invoking the [77:22] format method on top of it passing the [77:25] date that you want to pass and then [77:26] returning you the actual formatted date [77:29] right that's what this FMT function is [77:30] going to do you can even pass this date [77:32] as a parameter and can pass it over here [77:35] that is also fine but as you have [77:36] hardcoded the date over here I'm going [77:38] with this version how can I use it so [77:40] now you can do fmt first pass the local [77:44] enus and then you can pass any options [77:47] two options you learned so far date [77:49] style and time style. I'm going to teach [77:51] you a few more important options and [77:53] options you can pass as an object. You [77:55] can say in the date format I want the [77:58] month to be long, day to be numeric and [78:04] year to be numeric as well. Okay. And [78:09] now this is going to return me the [78:11] formatted date, right? Because fmt is a [78:14] function which can take a local which is [78:16] like this and a bunch of date formatting [78:19] options that you have passed and it is [78:21] going to return me the formatted date. [78:23] So if I just pass everything inside our [78:25] favorite log is going to print that [78:28] formatted date for you. You can see [78:30] March 15, 2026. The month is in long. It [78:33] says March day is in numeric 15 year is [78:36] in numeric. Okay. From long can I change [78:38] to short over here? Month become short. [78:41] You see it become m from March. When I [78:44] used long it was March M. But when I do [78:49] small it become M. So like that you can [78:52] change and you can take up the one that [78:54] you are looking for. Okay. Now you want [78:56] to compact the date little bit more. [78:58] Let's use another format. So to compact [79:00] the date I have used month as short [79:03] which is M day as numeric. So a compact [79:06] date where in a UI you have only small [79:08] real estate to show certain date format. [79:11] Yeah, you can go ahead and use this [79:12] compact format for that you are not [79:14] doing any string operation. You're not [79:15] cutting trimming any string rather [79:18] you're utilizing a particular date and [79:20] format given by Intel advantage because [79:23] now the same compact date if I just do [79:26] copy paste and I can do like de- [79:31] see this I'm getting for another local [79:34] all together. So you don't have to fix [79:36] it using any kind of eelss in your code. [79:39] You don't have to do string operation. [79:40] You don't have to keep any lookup table [79:42] for different languages. Just one line [79:44] of code is going to take care of [79:45] everything. Let's take some more [79:47] example. You want to display month and [79:48] year only. Yeah. In US or any other [79:51] local monthlong year numeric. See this [79:54] only March 2026. How about showing the [79:57] day of the week. So this time I made the [79:59] weekday as long as an option. I can see [80:02] Sunday month long day numeric. So you [80:05] can play around all these options [80:07] exactly what you want. And this is where [80:09] guys that MDN website what I have showed [80:12] you in the beginning will be very [80:13] helpful. This all all these options you [80:16] don't have to really keep it in your [80:17] mind. You can always go to the MDN [80:19] website and you can see which format [80:21] will be useful for your use case. Just [80:24] pick that up pass it as an option. [80:25] That's it. Similarly, we can also format [80:27] the time. This is where it is resulting [80:29] into a time formatting. You see it's a [80:31] 24 hours clock. Why it is a 24-hour [80:33] clock? because I specifically saying [80:35] 12-hour clock is false. If you just [80:37] remove this, this is going to be 12-hour [80:39] clock is going to say 8:00 p.m. So if [80:41] you want to print it in the 24 hours [80:42] clock, just pass this as an option hour [80:45] 12 as false. Hour I made two digit [80:47] minute I made two digits. See how it is. [80:49] I was talking about right that when you [80:51] want to log something log means uh not [80:54] only on console.log log but also in a [80:56] log that's at the server side and log is [80:58] a beautiful thing that gives a footprint [81:00] of what exactly happened and what [81:02] exactly happened also needs when it has [81:03] happened. So it means that time is very [81:05] important when certain things happen [81:07] when you're logging certain things. So [81:08] here is a full timer for log that you [81:11] can use here you are saying we are [81:12] formatting in this local but year is [81:15] numeric month is twodigit day is two [81:17] digit hour minutes everything in two [81:19] digit and it's a 24-hour clock. So if [81:22] you see over here this is how the date [81:24] and time is printed. So for every [81:26] occurrences in your log if you print the [81:29] log in this format that's awesome. Same [81:31] thing same format if you just take it [81:33] you know you just copy it paste it over [81:35] here just change the local to Japanese [81:37] like JA - JP and you can see how things [81:40] have changed right the formatting has [81:41] changed at least in the date case it has [81:43] changed. So these are the different [81:45] other powerful use cases, practical use [81:47] cases where you can use the options to [81:50] tackle each of the fragment of the date [81:53] and time in the date and time [81:55] formatting. Amazing. In the part one, we [81:57] touch base this one briefly. I'm just [82:00] going to reiterate again. Many times [82:02] there are confusions between time stamp [82:03] and time zone. I've explained that there [82:05] are also confusion between locals and [82:07] the time zone. Okay, let me define them. [82:09] A local which we have seen as EN - US [82:13] like J- JP all those things the local [82:16] actually determines how information [82:19] should be displayed a particular [82:21] language or a date and time or the [82:22] currency format etc. While the time zone [82:25] defines what time is based on a location [82:29] relative to the UTC. Okay. So far [82:32] whatever we have passed over here all [82:34] are local because we are talking about [82:36] the formatting. We are talking about the [82:38] formatting. These are all like one [82:39] certain format of data and type. Now I'm [82:41] going to talk about time zone. Time zone [82:43] means we are now going to talk about a [82:45] particular place in your world time zone [82:48] map. You remember like from the part one [82:50] we had UTC. If you go right side it is [82:52] UTC + 1 + 2 + 3 like that. If you go in [82:56] left side it was -1 -2 -3. India is in + [82:59] 530. Somewhere in New York we saw like [83:02] it was - 9. So all those things we have [83:04] learned in the part one. That's the time [83:06] zone. Now how can we actually see how [83:09] time zone influence some of this date [83:11] time format that's the objective to [83:13] show. So for that let us first take a [83:15] date in UTC. This is a date creating a [83:18] new date and this is a date in UTC [83:21] because this ends with Z right? We have [83:23] learned that in the part one. Ends with [83:24] Z means it's a UTC. Now we will take our [83:27] same formatter function. It actually [83:29] returns a formatted string. Okay. Now [83:32] let's define a few options. I have [83:34] defined a few time options that the time [83:36] style is short and dead style is also [83:38] short. Now if I do fmt fmt returns a [83:41] formatted string. I give the local enus [83:45] and then I pass the options. Before I [83:48] was passing the option directly over [83:50] here the object. Right now I have just [83:51] declared at the top so that I can [83:53] utilize it in multiple places. That's [83:54] how that's all about it. Then I will [83:57] just pass this inside my favorite log [83:59] function so that I can log it. is [84:00] logging 3/16/26 [84:06] 1:30 a.m. What is my date? If I look [84:09] into the date, it's 15th of March 2026, [84:13] 8:00 at UTC. Same date I am formatting [84:17] over here using the option called time [84:19] style and date style. But the output I'm [84:22] getting is the next day 16th of March [84:25] and it's 1:30 a.m. in the early morning. [84:29] Why? Here it is just 15th of March 8:00 [84:32] p.m. Here it is early morning 1:30 a.m. [84:35] next day. Why? Because this time is the [84:38] UTC time. I am doing everything here [84:40] from India. My browser is running on [84:43] India. India's time zone is UTC + 5:30. [84:47] If UTC is zero, then plus 5:30 from [84:50] there. If it is 8:00 in the night on [84:53] 15th of March and if you add 5 and 1/2 [84:56] hours means plus 5:30 5 and 1/2 hours [85:00] you cross 15th of March you go to the [85:03] next day 16th of March and you go to [85:06] exactly 1:30 a.m. So if you're not [85:08] passing any time zone over here, the [85:12] formatter function automatically takes [85:14] the time zone my browser is set to and [85:18] it formats the date for that particular [85:20] time zone. That powerful it is and [85:22] that's the impact of the time zone over [85:25] here. Now what if programmatically you [85:28] have to change this time zone. Yes, that [85:31] provision is also there. If you want to [85:32] change the time zone programmatically, [85:34] if you don't want that this particular [85:37] date time format to be displayed on the [85:39] time zone where your client is, the [85:41] client's browser's time zone, then you [85:43] can pass the time zone information as an [85:45] options over here. Let's see that. So [85:47] this is pretty much local time zone. [85:50] Okay, this is local time zone. Now if I [85:52] want it in American time zone like [85:55] American New York what I can do I can [85:57] take the same log for a moment but in [86:00] the time options I can dstructure it [86:02] normal JavaScript right to add a [86:04] property to an existing object and I can [86:08] pass the time zone as America New York. [86:12] Now do you see what is the time is 4 [86:14] p.m. So if you convert 15th of March [86:17] night 8:00 at UTC to the time zone of [86:21] America New York you go - 9 you go 9 [86:24] hours behind that's the reason it is [86:27] 4:00 p.m. over here 9 hours behind than [86:31] the 8:00 p.m. Okay. So this is how it [86:33] is. So in local time zone, this is the [86:35] time that's my local time zone. This is [86:37] in America and New York time zone. Let's [86:40] try few more. Now I'm trying in Europe [86:42] London time zone. So time zone I'm [86:43] passing as Europe London over here. You [86:46] see this again it will change right? How [86:49] about I try in Europe Berlin. So I here [86:51] I'll pass the time zone as Euro Berlin. [86:54] You see over here and of course it's in [86:56] Germany. So I'm formatting the date time [86:57] also in this particular format. You see [87:00] in Europe, Berlin it's completely a [87:02] different time. So these two things I [87:04] want you to put some focus over here. [87:07] This is just for formatting in a [87:09] particular language. This is the date [87:12] format. This is the time format. This is [87:13] just for formatting. However, this part [87:16] is for the actual time in that time [87:19] zone. That's the difference guys. If you [87:21] do a mistake here, you will never be [87:24] able to fix a production issue that [87:27] comes on date and time. You have to very [87:29] clearly know the first part is just for [87:32] formatting. Every geography on the earth [87:35] has some way to understand how the date [87:38] should be written, how the time should [87:39] be written. This first part is just for [87:41] that. Actual time would be represented [87:44] by this time zone. If you don't pass [87:45] anything, it's your browser's local time [87:47] zone. If you explicitly pass something, [87:49] yes, it is that time zone. Okay, I'll [87:51] give you another example. Do you see [87:53] over here how this formatting is done in [87:56] 150326 in Europe Berlin? This is correct [87:59] because this is the converted time for [88:01] the UTC to the German time like in the [88:04] Berlin and German guys understand this [88:07] date time in this particular format. Now [88:09] if you want to change this format but [88:11] still want to keep the Germans time, you [88:13] can just do enus. You'll see what [88:15] happened. The last one now the [88:16] formatting changed but the time is still [88:18] same. It was 9:00 24 hours format. Now [88:21] it become in 12-hour format. It was with [88:23] dot it become slash. Time is not [88:25] changing because you're changing the [88:26] first one. It's just the format changes [88:28] and you want to keep it in the format [88:29] that certain people understand from that [88:31] geography. That's why using the relevant [88:33] format along with the time zone over [88:35] here. I hope this is very clear guys. I [88:38] actually going how much level possible [88:40] for me to make you understand. I hope it [88:42] is clear. All right. So let's take Japan [88:45] in Asia Tokyo that's Japan. This is how [88:48] it is the time right now with the right [88:50] format. Awesome. You understood? Great. [88:53] If you like it, please post a like, [88:54] subscribe to the script so that you [88:56] don't miss out any other videos. Okay. [88:58] Let's talk about time zone names. You [89:00] would have heard about IST. But there is [89:03] a bigger form of that is called Indian [89:05] standard time. Similarly, for many other [89:08] go there will be a short form of a time [89:10] zone, the longer form of a time zone. [89:12] With the time how a time zone might [89:14] appear, everything differs. So let's [89:15] take some examples to understand [89:17] different time zone names. It's very [89:18] important. Okay. So I have taken a date [89:20] again in UTC. The date is 15th of March [89:22] but at 200 p.m. in UTC. Let's take a [89:25] time zone of America/ LA Los Angeles. [89:28] And here I have the same FMT function [89:30] like before but I have hardcoded many [89:32] things. Finally it returns a formatted [89:34] date. That's what it does. But I have [89:36] given some options hardcoded. For [89:38] example, I want hour in the numeric [89:40] format, minutes in the twodigit format. [89:42] Time zone. This is the time zone that I [89:44] want. and what kind of time zone name I [89:47] want. What is the format of it? That's [89:49] what I'll be passing to this particular [89:50] function. If I pass a long format like [89:53] log long while invoking this fmt with a [89:56] date, date is already hardcoded over [89:57] here. It will give me a long formatted [89:59] date. If I do short, it will give me a [90:01] short formatted date like that. So, let [90:03] me do this fmt and I'll start with short [90:07] sort and let me push this inside my log [90:11] function. So I see over here 7 a.m. PDT. [90:15] Okay. Why PDT? Because I have taken time [90:18] zone as America/ Los Angeles. So it will [90:21] show one of the time zone of America. By [90:22] the way, America, you know, it has [90:24] multiple time zones, right? Unlike India [90:26] which is having only one time zone. So [90:28] one of the time zone is PT. That's what [90:31] is showing. Okay. Now if I want to [90:33] elaborate that, I'll just copy this, [90:35] paste it over here. And instead of [90:37] short, I'm saying it's long. Now I see [90:40] specific daylight time that's what PD [90:42] stands for. So like that you can get [90:45] various different other formatted name. [90:47] For example, you want to get a short [90:48] offset name, you want to get a long [90:50] offset name, you want to get a short [90:52] generic name, you want to get a long [90:54] generic name, all these things will [90:56] appear over here like so based on what [90:59] kind of display you want to have for [91:02] your application, you can choose [91:04] different type of time zone names. Very [91:06] very useful, very very powerful. You [91:08] remember when we discussed about the [91:10] JavaScript data object in the part one, [91:12] I told guys JavaScript data object just [91:14] support two things, two type of time [91:16] zone. One is local time, another is UTC. [91:18] But with the INTL API, now you are [91:21] playing with any time zone of the world. [91:23] Now I'm getting into one of the most [91:25] exciting and one of my most favorite [91:27] section of INL that is relative time [91:30] formatting. Believe me, without this [91:32] relative time formatting means you have [91:35] to rely on data finesse. You have to [91:37] rely on moment JS. You have to rely on [91:40] some third party or you have to write [91:42] lot of logic to get it done. But you [91:44] will see it now how simple it is. So far [91:47] we were dealing with only dead time [91:48] format. Inl deadtime format. But now [91:51] let's kill that boredom. Let's talk [91:53] about intlative [91:55] deadtime format. And again same thing [91:57] you can pass a local enus. [92:01] And then you can pass a bunch of [92:03] options. Most used options are style and [92:07] numeric. I'm going to explain them and [92:10] let me take them in a variable called [92:12] RTF. Style and numeric are two different [92:17] options. There are few other options as [92:18] well but these are the most used one. [92:20] Numeric is auto means I'm telling inl [92:24] whenever you're returning me a formatted [92:26] relative time information you don't have [92:28] to always give me the information in the [92:30] numeric format. Sometime you can combine [92:33] to make it as a alpha numeric but [92:36] instead of auto if I give always this is [92:38] where it is always going to give me in [92:40] the numeric format style what are the [92:42] other different things are there just [92:44] like long there is a short there is a [92:46] narrow we going to see all of them okay [92:47] so for now let's go back to auto now [92:50] here is the fun what if I do RTF dot [92:53] format same like dead time format the [92:56] relative time format is also having a [92:57] format method to format things now here [93:00] you're talking about relative what does [93:01] it Mean if I'm standing today I want to [93:04] know what it was a day before what it [93:07] will be after 7 days what it was 36 [93:11] months before what it will be after 2 [93:12] years I want those kind of formatting [93:14] representation so let's do RTF dot [93:17] format minus one day and I'm going to [93:21] put this inside my log function see what [93:24] it prints it prints yesterday correct [93:26] now if I'm standing today so it is [93:28] always relative to today now if I'm [93:31] invoking it now minus1 day from today is [93:34] yesterday of course then what is minus 3 [93:36] day it will be 3 days ago correct now [93:39] imagine you have a date in the part one [93:41] we have learned about date difference [93:43] like and the day difference so you can [93:46] write your function to identify there is [93:48] how many days difference between today [93:51] and yesterday you found the number as [93:53] three now you do a string by [93:55] concatenating that three plus space then [93:59] days then space ago. This formatter [94:02] function gives you this one directly. [94:04] Why it is simpler? Because what if the [94:08] difference is one day? You cannot say 1 [94:10] days ago. It cannot be plural. It has to [94:12] be day. Right? For singular one day ago. [94:15] But for three, it has to be 3 days ago. [94:17] You have to write this logic sitting [94:19] now. If it is more than one, I'll be [94:21] saying days. If it is less than one, [94:23] I'll be saying day. All the things. Why [94:24] this formatter function is giving you [94:26] with all those control. Let's see some [94:28] more. How about this two minus one week [94:31] it says last week that's how it formats [94:33] minus two months two months ago you see [94:36] this so as and when this result you get [94:39] with your own computation between how [94:41] many months difference how many years [94:42] difference how many days difference and [94:44] you want to show that on your UI in a [94:47] much more better formatted way this is [94:49] how you'll be doing by the way if I want [94:52] to show this not in English in German [94:55] what will do you should tell D E D E [95:00] do you see this what is happening I [95:02] can't understand because I don't know [95:03] German but it changed the language [95:05] itself is changed beautiful isn't it [95:07] let's take some more examples minus one [95:09] year minus one year is nothing but the [95:12] last year one day now no minus I'm going [95:16] to positive next one day is tomorrowus [95:18] one day was yesterday this one day is [95:21] tomorrow 3 hour means in 3 hours minus 3 [95:25] day was 3 days ago One week will be next [95:28] week. Okay. Tell me what is zero day [95:30] will be? If I put zero here, put day [95:32] here, what it will be zero day? Of [95:34] course, it will be today, right? Because [95:36] the marker always starts from today, [95:38] right? What will be 0 second? If I put [95:40] instead of day here, if I put second, [95:43] what do you think? What it will be [95:44] output? It will be now. See, it is now. [95:47] Got the point? So, this is how you can [95:49] do the relative formatting. Now I'm [95:53] going to teach you another real or [95:55] something and especially with a library [95:57] like react or angular or whatever it is [95:59] where you build the applications and the [96:01] method name is format two parts same on [96:04] the formatter the relative time [96:05] formatter not on the date time formatter [96:07] you have a method called format two part [96:09] it takes a similar kind of argument [96:11] let's say minus 3 day okay I'll take [96:13] this one and I will pass over here now [96:16] if you call format it gives you the [96:18] formatted data minus 3 day it gives it [96:21] gave you 3 days ago. Okay. Now imagine [96:23] in your React application you want to [96:25] make these three bold days in blue [96:28] color. Ago is in red color. Of course [96:31] you won't use that kind of color but [96:33] imagine. So now what you'll be doing [96:34] after getting after formatting using [96:37] format minus 3 day after getting this [96:39] string you will be calling a method [96:41] called split which is going to split [96:43] this string based on this space and give [96:45] you an array with all these three days [96:47] and ego as element. Then you can do you [96:50] know map on top of that and then you can [96:52] do whatever you want to do. But instead [96:54] of that if you call format to parts this [96:57] is going to do the same thing but much [97:00] more safer way. So if I do log of I will [97:04] take this in a variable [97:06] called parts [97:08] and I will pass this parts over here. So [97:11] you see it is giving me an array of two [97:14] elements. The first element is an [97:16] integer which is saying three and the [97:18] second is the days ago. So this is the [97:21] meaningful way in thinks that it has to [97:23] be splitted. So that three you want to [97:25] put into one style days ago you can put [97:28] into another style. It is not splitting [97:30] days and ago again because it doesn't [97:32] make sense even from the UX perspective [97:34] because days and ago has to be together. [97:37] Okay. Why I'm saying it is much more [97:39] safer? Because if you just now change [97:41] this en us to de you see the enter [97:45] things get changed. Now it is returning [97:47] three things. Why? Because 3 days ago [97:49] has changed to this particular stuff and [97:51] now it thinks that it is meaningful to [97:55] split them into three different sections [97:57] because that's how the user from that [98:00] geography can perceive the information. [98:02] Three one thing days ago is another [98:05] thing. English speaking people can [98:07] understand that people understand [98:08] English can understand this separation [98:10] but for German the separation has to be [98:12] different that's how it is giving you [98:14] the output very very powerful thing guys [98:16] please make use of it I hope this blow [98:19] your mind and you will start using this [98:21] very very effectively uh by the way I [98:23] spoke about this style and this auto but [98:26] before that let me change it to us so [98:29] that all of us can understand clearly [98:31] everything is in English now if I change [98:33] the style to say short you don't see [98:35] them in this long format. See everything [98:36] becomes short, right? M O Y R things [98:39] like that. Now if you make it always in [98:41] instead of auto you see the [98:43] representation change. If I make it auto [98:44] you see the representation next week 2 [98:47] day now. But if I do always it will [98:50] honoring the numeric always like in 1 [98:52] day in 3 days in 1 week in 0 days in 0 [98:55] seconds. So whatever the ways it makes [98:57] sense for you use that particular style [98:59] and the numeric. The next thing you want [99:01] to learn is how JavaScript picks a [99:03] local. Okay, good. So, let's learn this. [99:06] So, here is a question for you. I have a [99:08] date, you know, in UTC. Again, I have [99:10] two locals over here, BN and ID. BN is [99:12] for Balanese local. ID is for the [99:14] Indonesian local. I have passed this [99:16] locals over here like both of them as an [99:18] array. So, what is the local that picked [99:20] up when JavaScript formatted this date? [99:22] Can you answer that? Now, one thing you [99:24] need to understand when you request a [99:26] local, JavaScript doesn't always have [99:28] exact match. It uses a negotiation [99:31] algorithm to find the closest match for [99:35] a supported local. Understanding this [99:37] prevents lot of surprises in production. [99:39] In this case, the BA is not a very [99:42] well-known local than ID. Indonesian is [99:45] a well-known local. So, JavaScript's [99:47] negotiation algorithm automatically will [99:50] picked up ID. It gives it a higher [99:52] priority for a local. And we'll be [99:53] formatting this date with Indonesian [99:55] local. Okay. Let me teach you one more [99:58] practical usage. Folks who works on [100:00] NexJS especially NexJS i8N part of it [100:03] they use the proxy or the middleware to [100:06] identify what is the local they have to [100:08] pick up dynamically. They use some of [100:10] these things. Okay for your client what [100:12] is the language that is set on the [100:14] browser. How can you get it? You get it [100:16] using navigator.language. Navigator [100:18] JavaScript object widely available under [100:21] the window object. If you do navigator [100:23] dol languages, it is going to give you [100:25] all the languages set on your browser or [100:27] your or if your customer is using your [100:29] application, your customer's browser, [100:31] just take it inside a variable and then [100:34] do a console dot log of user locals. [100:38] Let's see what it prints for me. So, [100:39] it's printing 10 locals because this is [100:41] how I have set up my languages. The [100:43] first one is English in India, then [100:46] Bangla, then Spanish, German, you know, [100:48] I have Chinese because I have to test [100:50] some things. I just drag and drop going [100:51] to my browser settings and languages. I [100:53] have bunch of languages. I have some [100:55] unknown language called Xhosa or HOSA [100:58] for testing my localizations multiple [101:00] times. Okay. Now let's say your [101:02] applications having certain locals [101:03] defined and you have defined them in [101:05] this particular browser. These are your [101:07] applications master local. Now how can [101:09] you ensure that when you're doing [101:10] formatting JavaScript picks up the best [101:13] possible local match for you? Because [101:15] your browser is giving this many local. [101:17] You also have this applications local. [101:19] What is the best match JavaScript can [101:21] find among the user locals and the app [101:23] locals. Okay, for that purpose INTL [101:29] deadtime format gives you a function [101:31] called supported locals of here you pass [101:35] your user locals and then you pass an [101:37] option that how you want this match to [101:39] happen. There is a property called local [101:41] matcher. You can pass it as a best fit [101:44] and this gives you the negotiated local. [101:47] So if I just take this into a variable [101:50] called negotiated [101:52] and I print this [101:56] log of negotiated local. Yeah, now I get [101:59] all the negotiated local. So if you see [102:01] from here xh has gone because javascript [102:03] thought xh is something that it cannot [102:05] support after doing this negotiation. So [102:07] these are the locals that are supported. [102:10] I should not be using console.log, isn't [102:11] it? It should be log always. All right, [102:13] we know this, right? intel. dead time [102:16] format and then call the format function [102:18] on top of that and get a formatted date. [102:20] Now one thing about performance [102:23] creating an inl.etime [102:25] format this object inl.etime time format [102:29] is not cheap. Under the hood, the [102:31] browser or the NodeJS environment, [102:33] wherever you're using it, has to parse [102:35] the local, negotiate the best match, [102:38] load the relevant uni code data. You [102:42] remember the CLDA database we spoke [102:43] about, then compile the format pattern, [102:46] set up an internal state for it. Lot of [102:48] such things it has to do. Now if you [102:50] doing the same thing like 50 60 70 times [102:54] in your code you are going to make this [102:56] calculation 50 60 70x slower. So how you [103:00] should be handling this? You should [103:02] never create a function like this where [103:04] you are actually calling intel. Time [103:07] format and call this function multiple [103:08] times in your code. Rather you should [103:10] use some amount of caching and [103:12] refactoring. The correct way of doing [103:14] would be create the formatter once. Once [103:16] the formatter is created then create a [103:18] function using this formatter you can [103:20] format it. This format is not costly but [103:23] creating this formatter for this [103:25] particular local a particular time zone [103:27] with a particular style is very very [103:29] costly. So always create the formatter [103:31] somewhere outside and then that [103:33] formatter use it everywhere in your [103:35] function or create a function for the [103:38] format and use that formatter function [103:40] everywhere. That's how you should be [103:41] using. Please keep this in mind [103:42] otherwise your application will be [103:44] unnecessary slow. I'll show you a [103:45] pattern that I use very often. I create [103:48] a formatter cache using the map. You [103:50] know what is map in the 40 days of [103:52] JavaScript course. I have taught you map [103:55] set hashmap hash set everything. So you [103:58] can take a look into that. So this is a [104:00] formatter cache that I will create and [104:02] using this cache I create a function [104:05] called get formatter. Okay, it takes you [104:07] see local and options. Those are the two [104:09] things your date formatter also need if [104:11] you remember. Then I create a unique [104:13] key. The unique key is for this [104:14] particular local. What are the options? [104:16] I combine them and I create a key. And [104:19] what I do I first check whether for the [104:22] same local same options somebody have [104:25] already asked me a formatter or not. If [104:28] no in that case what I do I put that [104:31] into cache and then I return the [104:33] formatter. Okay. If it is already found [104:35] in the cache I directly return the [104:37] formatter. So it's a cache thing right? [104:39] If you found in the cache it's a cash [104:41] hit. you directly send it from the [104:43] cache. If it is not found in the cache, [104:44] it's a miss. You first set in the cache [104:46] and then you return from the cache. [104:49] Right? So this is how you should be [104:51] maintaining a formatter cache. And once [104:53] you have the formatter cache, you can [104:55] now use the formatter cache. Create a [104:58] function for formatting the data. Take [104:59] the date local and option. Here the [105:01] formatter function get formatter [105:02] function is going to return a formatter [105:04] either from the cache or creating one [105:06] putting into the cache and then [105:08] returning. Getting the point? But you [105:10] are not creating it again and again [105:11] right the expensive operation. I hope [105:13] this makes sense to you. Now the last [105:14] thing with the inel API we are going to [105:16] learn what it is. We are going to talk [105:18] about the format range. Okay. So far we [105:20] spoke about only single date single [105:22] time. Let's talk about some to date from [105:25] date scenario. Here I have created a [105:27] formatter same intel. Time format for [105:29] this particular local with these [105:31] options. Month should be long day should [105:33] be numeric. Year should be numeric. [105:35] Let's take some dates. One start date [105:37] and multiple end dates. On the first end [105:39] date, it's a same month, same year of [105:41] the start date. In the second end date, [105:43] it is a different month than the start [105:45] date. In the last end date, it's a [105:47] different year altogether than the start [105:49] date. Now, we are going to format the [105:51] range. Range means from this to this. [105:54] For that, I already have this formatter. [105:56] I'll take this formatter [105:59] and I'll do log of formatter dot there [106:02] is a method called format range. And [106:05] here first I'll pass start and end one. [106:09] So look into this March 15 to 20, 2026. [106:13] It is showing only in terms of date [106:15] because the dates are both the dates are [106:17] in the same month same year. So there is [106:19] no use of repeating the month like in a [106:22] different way. So March 15 to 20 that's [106:24] how it is formatting. Now if I take the [106:27] same thing twice and here I'll do for [106:31] the number two and here I'll do for the [106:33] number three just to show you the [106:34] difference. Here it's automatically [106:36] recognize it's a different month [106:38] altogether. So it has to put the month [106:41] March 15 to April 10th but again it's in [106:44] the same year. So year was not repeated [106:46] in both the cases. But in last case year [106:48] has to be repeated because they fall [106:50] under different years. Isn't it? So it [106:52] is 2026 to 2027. This is how it is [106:55] giving you the formatting. How best is [106:57] this? So I hope you learned something [106:59] new. You learned a lot about Iintel, [107:01] isn't it? So how about bringing [107:03] everything together and create something [107:06] which is very very useful. So what I did [107:08] I created an npm package last night [107:09] only. I did that. Whatever we have [107:11] learned in this session plus few other [107:13] nitty-gritty things putting together I [107:16] have created an npm package that is not [107:18] dependent on any external libraries for [107:20] date and time formatting purely uses the [107:22] INTL package of JavaScript the INL API [107:26] and it gives you a bunch of utility [107:29] stuff like this you know how to format a [107:31] date format a time format date and time [107:33] formatted local date time ago you know 3 [107:37] days back 2 days back get month name get [107:39] day name format format the range is it [107:42] today was it yesterday is it tomorrow [107:45] start of the day bunch of methods bunch [107:47] of utility methods what I want is you [107:50] can take a look into this npm package [107:51] install this npm package with all these [107:53] commands that are given over here try it [107:55] in your JavaScript or the typescript [107:56] project give me a feedback this is an [107:58] open source project you can always go [108:00] ahead and click on this over here this [108:02] repository will take you to the open [108:04] source GitHub repository if you think [108:06] that there is something to be added on [108:08] top of it something to be modified ified [108:10] you want to take part in this opensource [108:12] project to make it even better you are [108:14] most welcome and you can do that here [108:16] there is a contributing guide that you [108:18] can take a look and if you like this [108:20] work go ahead and start this repository [108:22] the link to this package in the [108:24] description of this video please take a [108:25] look and give it a try none of my course [108:28] really end without giving you task and [108:30] assignments actually that's how you [108:32] learn better you know you have learned [108:33] from me like how to utilize it use it I [108:36] have told you about this npm package and [108:38] everything but until unless you get down [108:40] and try to tickle your brain to do [108:43] something you don't learn. Well, so [108:45] that's the reason under day 41 there is [108:48] something called task.md file. Okay, I'm [108:51] going to show you on GitHub where [108:52] exactly it will be available. But look [108:55] at this task. There are like close to 20 [108:58] task already over there. So take your [109:00] time and try to solve this. Everything [109:03] that you have learned in part one and [109:05] part two is going to help you to solve [109:07] these problems. Please give it a try. [109:09] Take your time. There is no hurry. All [109:10] right. All the source code is in [109:12] github.com/tapascript. [109:14] Please feel free to follow this [109:15] organization. Come to repositories. You [109:17] will have 40 days of JavaScript. I have [109:19] added this datetime initiative also [109:21] under 40 days of JavaScript. In case [109:23] you're not aware, this is a full-fledged [109:26] course to teach JavaScript to learn [109:28] JavaScript in much more depth with lot [109:31] of task and assignments. So there is a [109:33] day 41 where the part one video part one [109:37] chapters are already there. Once I [109:38] publish this part two video, you will be [109:40] able to see the part two lesson related [109:42] details, the source code and also the [109:45] task.md for you to look into the task [109:48] and do. You're always welcome to join [109:49] Tapascript Discord. This is where we [109:52] learn things together. If we do any kind [109:54] of assignment, we post under task [109:56] assignment stuff. You can see people are [109:58] posting over here. developers help each [110:01] other and whenever I have time I have [110:03] bandwidth I definitely pitch in and try [110:05] to help folks on JavaScript side of it [110:07] react side of it you can see a lot of [110:09] things kind of going on over here so [110:10] feel free to join Tapascript discord as [110:13] well next we'll get to part three part [110:15] three something that I'm genuinely [110:17] excited and interested about where we're [110:19] going to talk about the temporal API [110:21] what exactly it is it is something that [110:23] was long overdue the problem that we [110:26] faced with JavaScript date object those [110:28] immutability problem etc. All are going [110:31] to go away with the temporal API. With [110:33] modern JavaScript, temporal API support [110:35] is already there with the modern [110:36] browsers. So you will be able to utilize [110:39] and use many of those methods already. [110:42] Let's see them together. Let's [110:43] understand those things in part three. [110:45] So that you will know handling date and [110:48] time with legacy with the current state [110:51] of things with Intel API and also with [110:53] things that are upcoming in your [110:55] JavaScript bucket. I hope you also [110:57] equally excited for it. Stay tuned [110:59] coming soon and don't forget to [111:01] subscribe to Tapascript because that's [111:02] where you get lot of awesome fundamental [111:05] content. I was fixing a bug with my team [111:07] and it was on date and time. The bug was [111:09] a user's booking was showing up a day [111:12] earlier for anyone in the time zone that [111:15] is behind UTC. After some time me and my [111:18] team traced the bug in a single line and [111:20] the line was this. That's it. That is [111:23] the one line was destroying the date for [111:25] almost half of the planet because [111:27] JavaScript's date object the new date [111:29] with a date only string pares it as UTC [111:33] midnight not as local time zone [111:35] midnight. So if a user in New York open [111:38] the app and what it should be 16th of [111:41] June it renders at 15th of June. So we [111:44] fixed it and we shipped it to [111:46] production. Then 3 days later a new bug [111:48] came in and that also was on date and [111:50] time and it didn't stop there. It was [111:52] keep coming. Then we slowly realize the [111:54] problem is actually not in our code. It [111:56] was rather in JavaScript's date object. [111:59] In case you guys are not aware, [112:00] JavaScript date object was written in [112:02] just 10 days in 1995 and it was copied [112:06] from Java's Java.util.class [112:09] which was deprecated years later. But [112:13] unfortunately in JavaScript we have [112:15] carried the date object for last 30 [112:17] years. But that ends now. In 2026, there [112:21] is finally a proper replacement of it. [112:23] And in the next 15 minutes, I'm going to [112:25] show you exactly what it fixes, how it [112:28] fixes, and why it is the number one [112:31] replacement. That is a temporal API. [112:33] Guys, let's go get started. Before you [112:35] go anywhere, let me tell you clearly [112:37] what is this video is and what it is [112:39] not. This video is not the complete [112:41] course on temporal. That's not possible [112:43] in a single video and there is a [112:45] separate series required which is [112:46] coming. This video is more about an [112:49] orientation. The orientation of mindset [112:52] as a JavaScript developer we have used [112:54] date and time in a different way with [112:56] libraries without libraries. Now it's [112:58] time that you fix your mindset properly [113:01] so that hereafter whenever a situation [113:04] comes to handle date and time you will [113:06] always think about temporal. And I'll [113:08] make sure that in next 14 minutes that [113:10] happens. Let me now show you some of the [113:12] actual problem with the date object. [113:15] Here is a very innocent looking code, [113:17] isn't it? You have a function called get [113:19] next week which takes a date and then [113:22] you increment the date by 7 days. It [113:24] means if the date is 15th of November, [113:27] after this the date is supposed to be [113:29] 22nd of November. Okay. So now you are [113:33] saying today is 15th of March 2026. A [113:36] date that I have picked up. Then you [113:38] pass this date today to get the next [113:42] week. console.log log next week dot to [113:45] date string I will get 22nd of March [113:48] because today is 15th and we have [113:50] incremented by 7 hence we got next week [113:53] as 22nd. Fair enough. Now as a [113:55] programmer my expectation is that today [113:58] should not be changed because today is [114:00] today and we are just incrementing it by [114:02] 7 days to get the next week. But what [114:04] happen if I do console.log of today [114:08] string I see today is also changed to [114:11] 22nd. today is gone. The function today [114:15] this particular function today because [114:17] in JavaScript date objects are mutable. [114:20] Any method that changes them changes the [114:23] original object in the memory. You [114:25] always have to remember to clone the [114:27] date object before you perform any [114:29] operation to that. Now you know what [114:31] nobody always remembers. People forget [114:33] and that's where bugs get introduced. [114:35] Every single JavaScript developer has [114:38] been burned by this particular bug. [114:40] JavaScript data object sell it as a [114:42] feature but I say it's a bug. What month [114:45] is this? When I create a date with a [114:47] date object and I pass the month value [114:49] as two. Any normal human being will [114:52] think it is February because January is [114:54] the first month and the two represent [114:57] the February. But in JavaScript date [114:59] object zero means January, one means [115:01] February. This has been confusing [115:03] developers for last 30 years. There is [115:06] no good reason for it. It was a mistake [115:08] in the language itself. So that's the [115:10] second bug. Can you do this with [115:11] JavaScript data object? No, you cannot [115:14] do this because the JavaScript's data [115:16] object only knows two time zones. One is [115:19] UTC and other is your local missions [115:21] time zone. That's it. It doesn't know [115:23] any other time zone. So you cannot do a [115:26] New York time passing a New York time [115:28] zone. You cannot have a method called [115:30] two time zone and then you pass another [115:33] time zone. You cannot do all these [115:34] things. you have to use the INTL API to [115:38] display this or raw offset mathematical [115:41] logic by yourself or reach out for [115:43] another library which can do this. So [115:45] this is third problematic area with the [115:47] date object. And now is the worst part [115:49] about all four of these bugs because [115:52] they are silent. Date doesn't throw any [115:55] errors whatsoever when all these things [115:57] happen. It just quietly gives you the [116:00] wrong data. And just imagine wrong date [116:02] data in production can mean wrong [116:05] invoices. It can mean wrong [116:07] appointments. It can mean wrong [116:08] compliance records. It can be [116:10] devastating. Isn't it? Now this is [116:12] another bug and this is related to DST. [116:15] That is your daytime saving. So what [116:17] happened when spring forward happened on [116:19] March 8th say 2026 at 2:00 a.m. the [116:23] clock jumps to 3:00 a.m. That's what we [116:26] call as DST. So on that day clock jumps [116:29] from 2:00 a.m. to 3:00 a.m. for DST. So [116:32] literally 2:30 a.m. doesn't exist that [116:35] day. Now this particular code is a valid [116:37] JavaScript code. You can do 2:30 even [116:40] for a time zone where DST is applied. [116:43] JavaScript silently adjust it for you. [116:46] You never know it happened. There is no [116:49] error. There is no warning. Just wrong [116:52] data in production. This is where the [116:54] date object is absolutely absolutely [116:57] wrong choice in a programming language [116:58] like JavaScript. Now it's time to do the [117:00] mind shift. The single biggest shift in [117:03] temporal is this. Instead of one type [117:06] that tries to do everything in case of [117:08] date object, right? Temporal gives you [117:11] seven specialized types. Each one [117:15] designated for a specific kind of value. [117:18] And that's amazing. To give an analogy, [117:20] you can think it like this. The old data [117:22] object is like a Swiss army knife, [117:25] right? It technically has all the tools [117:27] in it, but you can never get to the [117:29] right one without cutting your finger. [117:31] At the same time, when you think about [117:32] the temporal, temporal is like a proper [117:35] toolbox. Whatever you need, you can just [117:37] pick up and get your work done. I hope [117:39] this analogy makes sense. Let's go over [117:41] each of these type one by one so that we [117:43] can understand the differences. The [117:45] first one is called temporal.plain date. [117:48] You use that when you need a date on the [117:50] calendar. No time only date the calendar [117:52] date no time no time zone usually you [117:56] use this for birthdays deadlines [117:58] holidays right where you generally work [118:00] with the dates you don't need any time [118:02] you don't need any time zone then [118:03] similar to plain date you have something [118:05] called plain time a time of the day no [118:08] date no time zone used for opening hours [118:11] for a store alarms recurring times etc [118:14] so I have given all this usage and this [118:16] code is in the GitHub the link is in the [118:18] description you can always go and read [118:21] more about it later point in time. But [118:23] now understand then you have temporal [118:25] dot plain date time. Before we had date [118:27] and time now we have plain date time. [118:30] This is date and time combination but no [118:32] time zone. Remember no time zone used [118:35] for this kind of cases. Our standard [118:37] meeting is every Monday at 10:00 a.m. [118:40] Each office observes in their own time [118:42] zone. Right? This particular meeting. So [118:44] in this kind of use cases you will use [118:46] temporal.plain date time. So far we have [118:48] seen what is for date, what is for time, [118:51] what is for date and time together but [118:52] no time zone. Whenever you need date [118:55] with time zone, you will use something [118:58] called zoned temporal.zone date time. [119:00] This is the most powerful one. You will [119:03] use this when you need date time plus [119:05] full time zone with DST awareness. Think [119:09] about it how powerful it is in case of [119:11] date object to deal with the date to [119:14] deal with the time to deal with the time [119:15] zone to deal with the DST doing all of [119:18] them together is almost impossible is [119:21] nightmare there will be bugs and you [119:23] used to go to third party libraries [119:25] multiple libraries to handle this now [119:27] JavaScript provides you out of the box [119:29] something called temporalzone date time [119:32] to take care of this when you use that [119:34] you use it for scheduling on the [119:35] calendar that's what my 9:00 a.m. could [119:38] be 8:00 p.m. somewhere else, right? [119:40] Calendar app usercentric times. So, here [119:42] is an example temporal.zone date time [119:45] form. You pass the date and time and you [119:47] also pass the time zone. This is [119:49] something we could not do with the date [119:51] object. We have seen it before. Then we [119:53] have something called temporal.instant. [119:55] This is an exact point on the timeline. [119:57] No calendar, no time zone. When do you [119:59] use it? Use it for logging. You're [120:01] logging something into your logger, [120:03] right? Or you need a time stamp. Then [120:04] you have temporal.plain plain year month [120:06] a month in a year used for usually in [120:09] invoices for the billing cycles, credit [120:11] card expiry and all those situation. [120:12] Then the last one is temporal dot plain [120:15] month day here month and day together [120:17] but no year used for annual recurring [120:19] dates like birthdays, anniversaries etc. [120:22] So these are the seven different types [120:23] that temporal provides so that we can [120:26] use them based on the usage and the use [120:29] cases. Now you notice something [120:31] important over here the naming is also [120:33] intentional plain wherever it comes as [120:36] plain like here it means no time zone [120:39] attached it means that you are working [120:41] with a calendar representation no UTC [120:43] math required no offset math required [120:46] just the value that you need but [120:48] whenever you see the zone that's the one [120:50] that knows about the real world where [120:52] you can pass the time zone name it [120:55] handles your DST automatically and gives [120:57] you the correct wall clock time anywhere [120:59] where on the planet and the best part is [121:02] all these dates are immutable. The first [121:04] bug that we have seen in case of date [121:06] object the date was mutable today was [121:09] getting changed when we were computing [121:11] the next week. In this case it's never [121:13] ever going to happen. Here is an example [121:15] temporal.plain date form this is a date [121:18] that I picked up. This is the date you [121:20] can call it as today also and then I'm [121:22] doing on today or on this date just add [121:25] seven more days. So this is the syntax [121:27] that we need to master when you use [121:29] temporal. So this will give me the next [121:32] week's date. Now if I print my date two [121:34] string is still remain 15th of March if [121:37] you see here. But the next week string [121:39] has got changed to 22nd. So it means [121:42] this particular date is immutable. The [121:45] dot add method on this date is not [121:48] changing the date itself. It is giving [121:50] me a new date value altogether. So here [121:52] you don't have to remember to clone. No [121:55] set date gotchas, no mutation bugs, just [121:58] clean predictable immutable operations. [122:01] Apart from this mutability and [122:02] immutability, can we go through some [122:04] dramatic differences? What if you want [122:06] to get today's date? So you have new [122:08] date and you want to get only today's [122:11] date only the date part with the date [122:13] object. You have to do this circus new [122:15] date dot2 iso string. It will give you a [122:18] big string of today's date and time. [122:20] Then you will do a substring operation [122:22] on that. Do a dot slice get the first [122:25] few characters which will represent [122:26] today's date which is 16th of June 2026 [122:29] while I'm recording this video. But with [122:31] temporal no such circus why do you want [122:33] to do a string operation to get the date [122:35] today's date. You just do [122:37] temporal.now.plain [122:38] date ISO. That's it. And then it gives [122:40] you today's date. How simple is that? [122:42] Have you done a comparison using old [122:44] date object like this? I have 15th of [122:47] March 2026 and again 15th of March 2026. [122:50] Two dates and I want to know whether [122:52] they are same date or not. I don't want [122:54] to know whether they are same date [122:56] object or not. What will happen over [122:58] here? Of course, we know the object [123:00] works with references. So, console.log [123:02] D1 triple equals strict equality D2. If [123:05] I do, it will give me false because [123:07] these two are different objects. Of [123:08] course, if I do a lose equality also, it [123:11] is going to give me the false because [123:12] two are different object. But how would [123:14] I know if those two are pointing to the [123:17] same date? For that workaround that date [123:20] object gives me is that on D1 you have [123:22] to do dot get time and on D2 also you [123:24] have to do dot get time. This will give [123:26] you the millisecond representation and [123:28] then you equate them and then you figure [123:31] it out whether they are the same time or [123:32] not. This is a workaround. Why? Because [123:35] on the date object you are calling [123:38] another API to get certain [123:40] representation of the date and then you [123:42] are equating right. It is like holding [123:43] your nose like this. But in temporal it [123:46] is this simple. You have two dates again [123:48] created with temporal.plain date because [123:50] calendar date you just do t1 dot equals [123:52] t2. That's it. And if I print this it [123:55] will say it is true. How explicit it is. [123:57] Have you compared two dates using [123:59] javascript date object? How easy or [124:01] difficult it was. If you have ever done [124:03] you have written your own logic with [124:05] temporal you just do this [124:07] temporal.plain.compare [124:09] pass t1 and t2 is going to return an [124:11] integer. If it returns zero, it means [124:13] those are equal. If it returns minus [124:15] one, it means it's a before. If it [124:18] returns one, it means after. So, how [124:20] easy it is to compare two dates. Now, [124:22] that's the last one that makes your user [124:24] almost crazy that adding one day and [124:26] getting wrong hour is a real production [124:29] bug and this is related to DST. Temporal [124:32] handles it by default using zone date [124:34] time. It knows about DST. You don't have [124:37] to think about it. You don't have to [124:38] write any extra code. Here this code [124:40] says on 7th of March at 12:00 a.m. in a [124:44] time zone where DST is applied the DST [124:46] starts. If I add one day temporal [124:49] understand this is the DST date and it [124:51] compensate the day accordingly. You [124:53] don't have to do anything extra. Same [124:55] thing if you have to do with the date [124:56] object you'll be writing this big code [124:58] to handle this. Now the question is can [125:00] I use the temporal API today and write [125:02] the code for production? My answer is [125:04] yes. Now you will say if I go to can I [125:06] use and search for temporal I see that [125:09] it has a limited availability and the [125:11] support for some of the browsers like [125:13] Safari. Safari doesn't have any support [125:15] itself. How can I use this? Don't worry [125:17] about that. It has a great support on [125:19] Chrome page Firefox and etc. You can [125:21] start using it. Wherever there is a lack [125:23] of support there is a polyfill for you. [125:26] This is a polyfill. I have given the [125:27] link in the description as well. And [125:29] this polyfill is created and maintained [125:31] by TC39 temporal champions. the same [125:35] guys who build the spec for temporal. So [125:37] it's not a workar around is a reference [125:39] implementation. You can ship production [125:41] code with this. Now my recommendation is [125:44] start using temporal API from now on. [125:47] Write your dead logic with temporal. [125:49] Learn the types learn the mental model. [125:51] With safari things won't work but you [125:53] have the polyfill to work it out. Once [125:56] safari start adding the support for [125:57] temporal you can get rid of this [125:58] polyfill. That's it. All the source code [126:00] you have seen in this part or in the [126:02] entire series is in my organization [126:04] called github.com/tavascript. [126:06] Please feel free to follow this [126:07] organization because there are a lot of [126:09] interesting projects and then you can go [126:11] to this repositories. From there you can [126:13] go to 40 days of JavaScript because date [126:15] and time playlist is also part of 40 [126:17] days of JavaScript. Over there if you [126:19] scroll down you can go to day 41 [126:22] and here you already have this INTL and [126:26] the date API everything. Once I publish [126:28] this video, you will be able to see [126:29] temporal another folder over here where [126:31] all temporal related code will be there. [126:33] If you like my work, don't forget to [126:35] start this repository. Thank you very [126:37] much. So here is what we have done with [126:39] this whole series. In the first part, we [126:41] took care of understanding everything [126:43] about date around date around time the [126:46] basic concepts. Then in the second part, [126:49] we also understand the intel APIs we [126:51] understood the date objects etc. before [126:53] that and in this part we took all [126:56] insights the major insights about the [126:58] temporal API now the natural progression [127:02] is to create a different series on [127:04] temporal I'll be doing that but for now [127:07] I'm sure this will be enough for you to [127:09] start writing correct production code [127:12] where date and times come into picture [127:14] if this was of any help to you please [127:16] subscribe to tapascript I create content [127:18] which are fundamentally right and which [127:20] help you to get job faster thank you [127:22] very much for watching. We'll be coming [127:24] back again very soon.