WEBVTT 00:00.000 --> 00:15.000 And please welcome LIT to you who's going to tell us about the Temporary PI. 00:15.000 --> 00:16.000 All right. 00:16.000 --> 00:17.000 Hello. 00:17.000 --> 00:19.000 Very good morning, everyone. 00:19.000 --> 00:20.000 I am Aditi. 00:20.000 --> 00:24.000 And today I would be talking about Temporary, which is a new jazz script 00:24.000 --> 00:27.000 API for handling data and times. 00:27.000 --> 00:32.000 I'm sure you must have seen it on training on Hagueleus for the last few days. 00:32.000 --> 00:33.000 Yep. 00:33.000 --> 00:35.000 That's the one. 00:35.000 --> 00:38.000 But first, a little bit about myself. 00:38.000 --> 00:39.000 I'm Aditi. 00:39.000 --> 00:40.000 I'm from India. 00:40.000 --> 00:43.000 I work in the compiler team at Egalya. 00:43.000 --> 00:46.000 A compiler team works on a bunch of cool stuff. 00:46.000 --> 00:51.000 It's jazz standards, browser engines, LLVM rigs, risk drive, etc. 00:51.000 --> 00:54.000 I myself have mostly worked on jazz standards. 00:54.000 --> 00:57.000 Implementation of those jazz standards. 00:57.000 --> 01:02.000 Test those implementations and more recently on PDFs, etc. 01:02.000 --> 01:04.000 But enough about me. 01:04.000 --> 01:06.000 Let's talk about Temporary. 01:06.000 --> 01:08.000 So what is Temporary? 01:08.000 --> 01:14.000 Temporary provides easy to use built in API for handling data and times in jazz 01:14.000 --> 01:15.000 script. 01:15.000 --> 01:16.000 It's built in. 01:16.000 --> 01:22.000 So right now, most of you might be doing something like using an external library 01:22.000 --> 01:25.000 like moment to handle later nights. 01:25.000 --> 01:27.000 This removes the need for doing that. 01:27.000 --> 01:33.000 Which also saves you a bunch of payload, which can range from like a couple of dozens 01:33.000 --> 01:38.000 to 200 kilobytes depending upon the local data include. 01:38.000 --> 01:41.000 It supports jazz internationalization. 01:41.000 --> 01:46.000 That means it supports all time zones, including non-regorian calendars. 01:46.000 --> 01:51.000 It is strongly typed, which means that for every use case, 01:51.000 --> 01:52.000 there is a different type. 01:52.000 --> 01:55.000 Instead of one type that fits everything. 01:55.000 --> 01:57.000 It is immutable. 01:57.000 --> 02:01.000 That means you don't have to worry about any external code, 02:01.000 --> 02:06.000 modifying your function without your knowledge. 02:06.000 --> 02:11.000 And it's currently at stage three if you remember from UDRA stock earlier. 02:11.000 --> 02:17.000 It's almost ready and we're mostly waiting for a browser to finish implementing it. 02:17.000 --> 02:20.000 And we're expecting no major changes. 02:20.000 --> 02:21.000 Okay. 02:21.000 --> 02:27.000 So this is the biggest change in jazz script that is been in a very long time. 02:27.000 --> 02:31.000 So we obviously need to think about why do we need it. 02:31.000 --> 02:34.000 Well, that data API is terrible. 02:34.000 --> 02:41.000 So these are the problems that we identified very early in the beginning of the 02:41.000 --> 02:43.000 beginning of temporal. 02:43.000 --> 02:47.000 So these are taken from Maggie's blog. 02:47.000 --> 02:50.000 Who is one of the original architects of temporal. 02:50.000 --> 02:53.000 And also one of the developers on Moments JS. 02:53.000 --> 02:57.000 She has listed them in order of relative discussed. 02:57.000 --> 02:59.000 So let's just come through these. 02:59.000 --> 03:02.000 The first one is there's no support for time zones. 03:02.000 --> 03:05.000 Other than the use of local time and UDC. 03:05.000 --> 03:08.000 The passive behavior is very unreliable. 03:08.000 --> 03:11.000 And the data object is mutable. 03:11.000 --> 03:16.000 That means so if you have one there object and you're using it several times. 03:16.000 --> 03:23.000 But if something like set month or you do something like set month or set date. 03:23.000 --> 03:27.000 It can cause bugs because the original date object would be modified. 03:27.000 --> 03:29.000 The DST behavior is unpredictable. 03:29.000 --> 03:34.000 The computation API is a weird and there's no support for non-regorian calendars. 03:34.000 --> 03:35.000 Okay. 03:35.000 --> 03:37.000 So let's think about it. 03:37.000 --> 03:38.000 Can we fix them? 03:38.000 --> 03:41.000 Well, few things like computation. 03:41.000 --> 03:43.000 API has been weird can be fixed. 03:43.000 --> 03:50.000 But other stuff like mutability cannot be fixed because there's so much code out there that already 03:50.000 --> 03:51.000 relies on this. 03:51.000 --> 03:53.000 So we would break the web. 03:53.000 --> 03:54.000 Okay. 03:54.000 --> 03:59.000 So I mentioned strongly typed earlier. 03:59.000 --> 04:04.000 So let's take a tool through all the types that are present in temporal. 04:04.000 --> 04:09.000 The first one you should know about is temporal instant. 04:09.000 --> 04:12.000 Which represents an exact moment in time. 04:12.000 --> 04:19.000 It is represented as a lapse nanoseconds since the midnight of UDC run for 1970, 04:19.000 --> 04:21.000 which is the epoch time. 04:21.000 --> 04:24.000 It's just nanoseconds. 04:24.000 --> 04:26.000 It has no time zone. 04:26.000 --> 04:29.000 That means it has no daylight savings capabilities. 04:29.000 --> 04:30.000 It has no calendar. 04:30.000 --> 04:33.000 So there's no year month or day. 04:33.000 --> 04:38.000 And it's just a purely ever increasing number. 04:38.000 --> 04:43.000 Then there is a family of plane types. 04:43.000 --> 04:49.000 This is the most commonly used commonly used way of how we talk about time. 04:49.000 --> 04:53.000 We call it the world time. 04:53.000 --> 04:56.000 So there's a bunch of types in this family. 04:56.000 --> 05:01.000 We have plane date time, which has both the date and the times. 05:01.000 --> 05:03.000 And then we have plane date. 05:03.000 --> 05:05.000 So just date without any time. 05:05.000 --> 05:07.000 Then we have plane time. 05:07.000 --> 05:10.000 Which is just time without any date. 05:10.000 --> 05:12.000 So something like the break is at 12. 05:12.000 --> 05:13.000 5. 05:13.000 --> 05:15.000 And then we have air month. 05:15.000 --> 05:19.000 Which has no day or time. 05:19.000 --> 05:21.000 So something like September 25. 05:21.000 --> 05:23.000 And then we have month day. 05:23.000 --> 05:27.000 Which we would casually use to say something like my birthday is on March 14. 05:27.000 --> 05:37.000 So the question is why do we have this family of types with a progressively decreasing information? 05:37.000 --> 05:42.000 So this is so that you can accurately represent the data you have. 05:42.000 --> 05:47.000 For example, if you just had the date and no time, 05:47.000 --> 05:55.000 the way you would do it in the legacy date object is you would you would take a date and use midnight. 05:55.000 --> 05:58.000 But that doesn't work in most cases. 05:58.000 --> 06:00.000 Like that works in most cases. 06:00.000 --> 06:06.000 But that might not work in some cases where midnight escaped due to DST. 06:06.000 --> 06:12.000 For example, November 4, 2018, midnight didn't exist in Brazil. 06:12.000 --> 06:15.000 So that can cause very hard to track down bugs. 06:15.000 --> 06:16.000 Okay. 06:16.000 --> 06:18.000 Next up. 06:18.000 --> 06:23.000 This is this completes the types of temporal which represent the date and time. 06:23.000 --> 06:25.000 This is temporal zone date time. 06:25.000 --> 06:27.000 It is like in it is like temporal instant. 06:27.000 --> 06:29.000 It is an exact time. 06:29.000 --> 06:31.000 But it also has a calendar and time zone. 06:31.000 --> 06:33.000 So it follows the DST rules. 06:33.000 --> 06:38.000 And it also has a day month as a day month in a year. 06:38.000 --> 06:39.000 Okay. 06:39.000 --> 06:45.000 So this is we call family time as something that represents. 06:45.000 --> 06:47.000 And even that has happened. 06:47.000 --> 06:51.000 That has happened at a place on earth or will happen at a place on earth. 06:51.000 --> 06:59.000 And there's also one other type called temporal duration. 06:59.000 --> 07:05.000 And this is mostly used to for arithmetic. 07:05.000 --> 07:12.000 I will talk more about the arithmetic later when we walk through the code examples. 07:12.000 --> 07:13.000 Okay. 07:13.000 --> 07:19.000 So for example, I have selected three problems. 07:19.000 --> 07:22.000 That easy medium and hard one. 07:22.000 --> 07:27.000 And as we saw those problems, I will keep telling more about them. 07:27.000 --> 07:28.000 Okay. 07:28.000 --> 07:33.000 So the first question is, get a unique timestamp in milliseconds. 07:33.000 --> 07:39.000 So it this is a very popular question about. 07:39.000 --> 07:44.000 It's the number one top four requests on stack overflow about the legacy date. 07:44.000 --> 07:51.000 And when you think about it, so timestamp. 07:51.000 --> 07:54.000 That is an exact time. 07:54.000 --> 07:56.000 So we know we would use instant. 07:56.000 --> 07:58.000 But how do we get the current time? 07:58.000 --> 08:00.000 Don't think too much about it. 08:00.000 --> 08:02.000 I haven't told you that yet. 08:02.000 --> 08:05.000 And that's where the temporal noun namespace comes in. 08:05.000 --> 08:12.000 It is a namespace with functions that give you temporal objects representing the current date time or time zone. 08:12.000 --> 08:14.000 So for ISO, it's zero one calendar. 08:14.000 --> 08:16.000 That is the machine calendar. 08:16.000 --> 08:18.000 I will tell more about calendar later. 08:18.000 --> 08:21.000 You can get the temporal object. 08:21.000 --> 08:23.000 So you can get an instant or time zone ID, 08:23.000 --> 08:25.000 only time, et cetera. 08:25.000 --> 08:27.000 And then use it. 08:27.000 --> 08:29.000 So okay. 08:29.000 --> 08:31.000 So we got the current time. 08:31.000 --> 08:33.000 But how do we get the milliseconds? 08:33.000 --> 08:39.000 So each temporal object has a few read-only properties. 08:39.000 --> 08:42.000 And this is the set of all the properties. 08:42.000 --> 08:46.000 Not all the temporal objects have all these properties. 08:46.000 --> 08:51.000 Only the only time has every other object has a subset of these. 08:51.000 --> 08:59.000 For example, here doesn't exist in the temporal types without a calendar. 08:59.000 --> 09:00.000 Okay. 09:00.000 --> 09:03.000 So combining all of that information. 09:03.000 --> 09:06.000 This is how we would get the hyper milliseconds. 09:06.000 --> 09:10.000 The unique time stamp using temporal. 09:10.000 --> 09:17.000 Moving on to the second example, which is a pretty simple question. 09:17.000 --> 09:20.000 What is the date one month from today? 09:20.000 --> 09:23.000 Okay. 09:23.000 --> 09:27.000 In the legacy date object, you would do something like this, 09:27.000 --> 09:32.000 where you take today's date, which is where the date here is yesterday's. 09:32.000 --> 09:35.000 But you can take today's date or whatever date. 09:35.000 --> 09:42.000 And then you can easily print it using the local string method. 09:42.000 --> 09:44.000 But that's not good enough. 09:44.000 --> 09:46.000 I'll tell you why. 09:46.000 --> 09:51.000 Because you take the date and you set the month to the next month. 09:51.000 --> 09:53.000 And then output that string. 09:53.000 --> 09:55.000 That gives the wrong output. 09:55.000 --> 10:01.000 Because first February and first March are not exactly one month apart in the Hebrew calendar. 10:01.000 --> 10:11.000 So they are, but that's because not every calendar has the same number of days in every month. 10:11.000 --> 10:15.000 Hebrew calendar usually has 29 or 30 days. 10:15.000 --> 10:17.000 And February just has 28. 10:17.000 --> 10:21.000 So that makes the calculations go wrong. 10:21.000 --> 10:25.000 So let's talk about how we would do this in temporal. 10:25.000 --> 10:29.000 But before that, let's talk more about calendars first. 10:30.000 --> 10:33.000 So this standard calendar in machines is ISO. 10:33.000 --> 10:37.000 It's a given calendar, which is standardized. 10:37.000 --> 10:42.000 And the way books is standardized throughout the world. 10:42.000 --> 10:47.000 And it is pretty similar to the most commonly used calendar, which is the Gregorian calendar. 10:47.000 --> 10:53.000 You can almost always convert between the two without worrying about. 10:53.000 --> 10:56.000 Without worrying about. 10:56.000 --> 11:00.000 We're very worrying about too much, but there are few exceptions. 11:00.000 --> 11:03.000 A few cases where they still don't align. 11:03.000 --> 11:08.000 For example, the first week of the month, they have different rules for calculating that. 11:08.000 --> 11:13.000 But other than that, you can pretty much mentally convert between the two. 11:13.000 --> 11:20.000 But there are also other calendars, like Hebrew calendar, all the Hindu calendar. 11:20.000 --> 11:28.000 Which I have that different number of which are different from the ISO 801 calendar. 11:28.000 --> 11:33.000 So you can print the non ISO dates. 11:33.000 --> 11:37.000 But for adding, you need to do something more specific. 11:37.000 --> 11:40.000 So we'll talk about that. 11:40.000 --> 11:44.000 But first, we now have got the calendar sorted. 11:44.000 --> 11:48.000 Next up, let's talk about how we would add a month. 11:48.000 --> 11:51.000 So I mentioned duration earlier. 11:51.000 --> 11:53.000 So add or subtract. 11:53.000 --> 11:56.000 We have got two methods called add or subtract. 11:56.000 --> 12:00.000 So for every temporal type, we can get a temporal duration. 12:00.000 --> 12:05.000 And return a new temporal object to the same type by adding the duration. 12:05.000 --> 12:15.000 And we also have since an until on duration, which represents the time elapsed between two similar temporal types. 12:15.000 --> 12:17.000 Okay, so we have the date. 12:17.000 --> 12:20.000 I'll talk about how we get the date. 12:20.000 --> 12:22.000 And then we add a month. 12:22.000 --> 12:27.000 We pass a property back, which automatically gets converted to duration. 12:27.000 --> 12:38.000 So this is the right way of calculating, calculating a month, calculating the adding a month in users calendar. 12:38.000 --> 12:40.000 So we pick the calendar. 12:40.000 --> 12:42.000 The right calendar would every want. 12:42.000 --> 12:46.000 We get the current date using temporal now, plain date ISO. 12:46.000 --> 12:54.000 And use the width calendar method to insert that calendar into the date and then add the month to it. 12:54.000 --> 12:56.000 And then format it using locustring. 12:56.000 --> 12:58.000 Any users local calendar. 12:58.000 --> 13:04.000 Okay, so I hope things have been clear until now. 13:04.000 --> 13:07.000 Let's talk about a hard problem. 13:08.000 --> 13:11.000 So these are three compensations. 13:11.000 --> 13:15.000 I took this screenshot from our website of our conference. 13:15.000 --> 13:22.000 And we have to calculate what time are these compensations for me in my time zone. 13:22.000 --> 13:29.000 Okay, so we have three sessions in three different time zones on two dates. 13:29.000 --> 13:36.000 So we have July 23rd and 30th, two dates, and they are four other sessions on every date. 13:37.000 --> 13:39.000 For three time zones. 13:39.000 --> 13:42.000 So this is the information that we have. 13:42.000 --> 13:47.000 We have the two calendar dates that the sessions occur on July 23rd and 30th. 13:47.000 --> 13:54.000 And the start time of the sessions and the time zones that is 11 am AST, which is Australian Eastern Standard Time. 13:54.000 --> 14:01.000 And one PM E degree, which is Eastern Day like time, we have my time zone. 14:01.000 --> 14:07.000 And the arts in my local time at which I'm willing to be at my computer. 14:07.000 --> 14:15.000 So normally for something like this for calculating the time of conference in my time zone, 14:15.000 --> 14:18.000 I would just do simply something like I would take the time. 14:18.000 --> 14:22.000 I better remember I was there and hope that it tells me the right answer. 14:22.000 --> 14:26.000 But let's see how we do it in using temperature. 14:26.000 --> 14:29.000 So this is some work of a pseudo code. 14:29.000 --> 14:33.000 What we need to do for each session date. 14:33.000 --> 14:40.000 And for each session, we need to calculate the exact time when the session starts and ends on that day. 14:40.000 --> 14:46.000 I said exact time and we also have calendar and a time zone attached to it. 14:46.000 --> 14:48.000 So we would use this only time. 14:48.000 --> 14:54.000 And if the local time of my session in my time zone falls within the arts, 14:54.000 --> 14:56.000 then I'm willing to be at my computer. 14:56.000 --> 15:00.000 We just print the local time of the session in my time zone. 15:00.000 --> 15:07.000 So setting up, this is a small piece of code that we used to set up. 15:07.000 --> 15:15.000 We take, we have the dates that is 23rd and 30th. 15:15.000 --> 15:21.000 And then we have sessions array with the information about the time zone and the art at which the conference starts. 15:21.000 --> 15:25.000 We have the session length which is a duration object. 15:25.000 --> 15:30.000 And we have my time zone which we get using the temporal now times zone id option. 15:30.000 --> 15:35.000 So the two things that I haven't talked about yet, 15:35.000 --> 15:40.000 one of them is the from method that I haven't mentioned yet, 15:40.000 --> 15:44.000 which I'm using to construct the plane date and the duration. 15:44.000 --> 15:48.000 So let me, let me talk about the from method first. 15:48.000 --> 15:56.000 So there are two ways you can construct temporal objects using constructors and using the from method. 15:56.000 --> 16:04.000 So constructors are low level and they mostly require exact numerical information. 16:04.000 --> 16:06.000 So they're not recommended. 16:06.000 --> 16:10.000 So using constructors would be something like this. 16:10.000 --> 16:16.000 But you can also use from for high level cases. 16:16.000 --> 16:20.000 They're friendly, they accept property bags, ISO strings, instances, et cetera. 16:20.000 --> 16:22.000 And they're recommended in most cases. 16:22.000 --> 16:28.000 And this is how you would use the from method. 16:28.000 --> 16:31.000 And okay. 16:31.000 --> 16:36.000 So the thing, so we have got that we have set up. 16:36.000 --> 16:37.000 We have got the times. 16:37.000 --> 16:47.000 Now we need to compare the times to identify if I am online at those sessions or not. 16:47.000 --> 16:50.000 So we have two ways of comparing. 16:50.000 --> 16:54.000 Equals tells you we have got equals for every temporal type. 16:54.000 --> 16:59.000 And it tells you whether temporal objects or the same type are exactly equal. 16:59.000 --> 17:04.000 We also have a compare static method for every temporal object. 17:04.000 --> 17:07.000 And it's used for sorting, et cetera. 17:07.000 --> 17:12.000 You can pass it to a resort method to sort of the times. 17:12.000 --> 17:16.000 And for this case, we would use compare. 17:16.000 --> 17:18.000 So this is a small comparison method. 17:19.000 --> 17:24.000 We have got my coffee time where I wake up and my bed time. 17:24.000 --> 17:26.000 At which time I go to sleep. 17:26.000 --> 17:30.000 Because since we only have the time, we use the plane time. 17:30.000 --> 17:35.000 And we have a small function called if I can't be online at all. 17:35.000 --> 17:40.000 I have those times and we use the compare method to compare those times. 17:40.000 --> 17:45.000 And if I am online at those times, it returns true. 17:45.000 --> 17:46.000 Okay. 17:46.000 --> 17:51.000 So this is where the main calculation happens. 17:51.000 --> 17:53.000 We have got. 17:53.000 --> 17:57.000 So for each, we are looping through each date. 17:57.000 --> 18:00.000 That is the two ways that we had between each third and third year. 18:00.000 --> 18:05.000 And for each session on each date, we agree. 18:05.000 --> 18:09.000 We create a zone daytime object with the time zone. 18:09.000 --> 18:14.000 That was provided the time zone that was given. 18:14.000 --> 18:19.000 And use the plane time, which is the session start time. 18:19.000 --> 18:24.000 And that is how we get the session start in the time zone. 18:24.000 --> 18:31.000 But to get it in my time zone, we get the my session start in my time zone using with time zone. 18:31.000 --> 18:39.000 And then we get the session end time using by adding the session length, 18:39.000 --> 18:43.000 which was a duration object using the add method. 18:44.000 --> 18:47.000 And then we call the comparison method. 18:47.000 --> 18:52.000 And check if I can be online at the start time and the end time. 18:52.000 --> 18:57.000 And then if I can't be when we just format it up, which I'm trying to. 18:57.000 --> 18:58.000 Okay. 18:58.000 --> 19:04.000 So going through this code, there's a bunch of things that I haven't talked about yet. 19:04.000 --> 19:10.000 Let's do the zone daytime and also with the time zone. 19:10.000 --> 19:13.000 So first we'll talk about conversion. 19:13.000 --> 19:17.000 It is possible to convert between two temporal types. 19:17.000 --> 19:23.000 Using the two plane daytime or two plane day month, day etcetera methods. 19:23.000 --> 19:31.000 And for using these conversion types, what we need to do is we need to provide the additional information. 19:31.000 --> 19:36.000 That's missing from a current object to get a new object of a different type. 19:36.000 --> 19:43.000 So for example, for in this example, we have a plane date and we convert it, 19:43.000 --> 19:46.000 we want to convert it to plane date time. 19:46.000 --> 19:53.000 So we pass the time and that gives us an output which is a plane date time. 19:53.000 --> 19:58.000 And if there's any if you want to convert it to plane month day, 19:58.000 --> 20:04.000 then plane date already has the month day information in that case we read arguments empty. 20:04.000 --> 20:08.000 Okay. And so that's the conversion. 20:08.000 --> 20:12.000 Now moving on to modification. 20:12.000 --> 20:20.000 So we have with methods every temporal type which can be used to modify temporal objects. 20:20.000 --> 20:25.000 And the temporal objects are immutable, yes. 20:25.000 --> 20:33.000 I talked about that a bit earlier, but you can get a new temporal type with the modified new temporal object of same type. 20:33.000 --> 20:36.000 With the modified information. 20:36.000 --> 20:43.000 So with method takes on argument which is a property bag with some components of the same type, 20:43.000 --> 20:45.000 whatever you would like to modify. 20:45.000 --> 20:52.000 And it returns a new temporal objects, new temporal objects with the provided fields replaced. 20:52.000 --> 21:00.000 And so for example, if I had a date then and I wanted to replace the date. 21:00.000 --> 21:06.000 So we could use the we could use the with method, 21:06.000 --> 21:10.000 but there are separate with calendar and with time zone methods, 21:10.000 --> 21:16.000 the one that I used, I used with calendar earlier. 21:16.000 --> 21:19.000 And also in the previous light, I used with time zone. 21:19.000 --> 21:23.000 They are different because if both of them are provided together, 21:23.000 --> 21:26.000 we wouldn't know which one to use first. 21:26.000 --> 21:33.000 And with combining all of that code, we get the following output, 21:33.000 --> 21:38.000 which is the conference, which is the conference times in time zones. 21:38.000 --> 21:44.000 And it might seem like that's a lot of code for a very simple problem. 21:44.000 --> 21:49.000 But seriously, I wouldn't even want to try this with the legacy date API. 21:49.000 --> 21:54.000 And I hope that was helpful. 21:54.000 --> 21:58.000 This is the temporal documentation, now they're available at MDN, 21:58.000 --> 22:00.000 so you can go look at it. 22:00.000 --> 22:06.000 And yeah, if you want to read more, that's the temporal repository. 22:06.000 --> 22:11.000 There you can find the link to the playground, 22:11.000 --> 22:14.000 where you can play around with the polyfill. 22:14.000 --> 22:17.000 And these are the link for the MDN docs. 22:17.000 --> 22:19.000 And thank you so much.