How to Outsmart Time: Building Futuristic JavaScript Apps Using Temporal

Hello and welcome, everyone. I'm Ujwal. You can find me on the internet at whyzacooking. If you want to run into me on Twitter or GitHub, I'll have a terrible how terrible this talk is or want to talk about Tempo or TZ39 stuff. But today we're going to talk about building futuristic JavaScript applications in Tempo. So let's get into it.

Because I'm a self-obsessed person. Let's first talk about me. So, I have a compiler's hacker, Regalia. For those of you who don't know, it's a free software consultancy in Spain. We work on a bunch of cool things. We work on browsers, compilers, standards like the ones I'm going to talk to you about today and a bunch of cool Linux stuff. I am also a TC39 delegate, which is why I'm talking to you about these things. I am one of the editors of Ecma 402 and the champion of the proposal that we talked about today and also happen to be one of the co-collaborators of O.J.S.

Just to give you a little recap about the history of the whole temporal thing, what the buzz is all about, if you've used the date object in JavaScript ever to do any sort of date time handling, you would know that it is severely outdated. It has serious issues. It dates at least back to 1985, which is before I was born, so how is that for a metaphor? But it needs a lot of repairs, which means that if you're writing any serious date time handling application, you're probably using some popular third-party libraries. They're pretty popular these days in the JavaScript ecosystem. You're either using Moment or Luxon date functions, and, well, they fill a really important role in the JavaScript language, but there's still quite a few problems. There's still deficiencies, if you follow JavaScript drama not so long ago, Lighthouse, which is a tool that sort of gives you performance tips regarding a JavaScript code, started flagging applications that use Moment, asking them to use something that would use less bundle size. So that's, for example, one of the problems that cannot be solved in the user space, among a bunch of others that I'm going to talk to you about. But because of all these problems, we realized that something needed to be done on the programming language level itself. Thus I bring in Temporal.

So Temporal is a state-of-the-art, daytime handling proposal in JavaScript. It brings you not only to the present, but, as you will see in the next few slides, right into the future. One of the most interesting challenges that we had when designing the Temporal API was certainly about going to sort of conflicting things, right? There's JavaScript of proposals that you see that are more specifically geared towards advanced users, you know them when you see them. There's others that are more sort of geared towards beginners, they make your life easier, but not as much if you have been writing this language for like 10 years, and in Temporal, the beauty of the Temporal proposal is that it tries to pair an ergonomic API with a special focus on some of the most common use cases alongside some really powerful features that accommodate some of the most complex use cases, some of the use cases that have never been accommodated so far. Things including local calendar support, so including calendars like the Hebrew or Islamic calendar or custom time zones of calendars. These are truly features that have been so far overlooked. So temporal, the thing that I talked about just now, is now stage 3, which is great news.

Except we don't really know what that means. So just to sum it up real quick, in the interest of time, it means that all the tiny details have been discussed. You've been sitting around in our chairs for a long time and realized that we've basically exhausted everything that we could have done while sitting in our chairs. So the specification text has been approved, the committee is now satisfied with the general design, and now the idea is to start implementing and using temporal.

So for implementers like us, that means that we will start implementing things in different polyfills. We will start implementing temporal in different browsers, and for you amazing JavaScript developers, it means that you can start using temporal in your applications, including production. Just to give you a quick idea of the huge, honestly, API surface of temporal, you have a number of these classes that we're going to talk about in the next few slides. Just to briefly go over them, there's instant, which happens to exist in the exact time space. So it knows the exact time that it's happened since the epoch. And then there's a bunch of fuzzy time types. So there's plain date time, plain time, plain date. They happen to be all subsets of plain date time. So they talk about more fuzzy notions of time and dates. So, hey, 80 a.m. in the morning doesn't really matter how many exact nanoseconds have passed, right? And then there's a zone date type, which is sort of the ubermensch of all these types. It encompasses all the different use cases that we so far offer, and it can be completely replaced. It can replace totally date objects, but hopefully you would realize that you need something much less powerful. There's time zones and calendars, which sort of play between these. And then there's durations, which are used mostly for map.

To quickly summarize this, because this is going fast, but hopefully I'd be able to at least draw your attention in the span of 20 minutes, instance represent absolute points in time. So something as granular and as boring, as you may say, as a number of nanoseconds that have passed since the Epoch, which in this case is the Unix Epoch, 1970. And then there's the plane types, plane date time and friends who deal with the regular world clock time and calendar dates. So, for example, if you're building a fitness tracker, it doesn't really matter if I'm in Moscow or in Amsterdam. All that matters is that I wake up at 8 a.m. and eat a lot of bagels. Don't go for a run. Calendars refer to human calendars, so, you know, in common understanding, it would refer to the Gregorian calendar, which is pretty popular. It may refer to the more obscure calendars, but still used throughout the world, like the Buddhist calendar or the Hebrew calendar, Julian calendar, and then there's time zones that refer to an exact offset, so something like plus one hour from UTC or a more fuzzy human time zone, so something like Europe slash Amsterdam, which may represent different points of time depending on what time you're talking about and if it's summer or not. Zone date time, as I said, is the combination of an instant and a time zone, so it takes the boring instant and it pairs it with the time zone to project a date time from it, right? So if you know which time zone you're in and you know the exact number of nanoseconds that have passed, then you can give any information, you can tell me what time of the day it is and so on. It's the most powerful thing.

Yeah, and then of course all the arithmetic operations that are done in this space are done in durations. So what is the difference between two dates or two times? Well, they're all durations. So enough talking, right? Let's get down to business. Let's make an invoice calculator, which happens to be a not so common application of dates and times, but it does happen to be sort of a power user in terms of computation. And let's see how simple it is with Tempo.

So step one, if I was posing a calculator like this, would be to pick a date time picker. So all the cool kids have told me that these days, you would pick a date time picker based on the rent-with-strategy. So whatever library you're using, you pick something based on that, right? The key point is that it should return an ISO 801 string. So this is the string persistence format that is accepted all over the Tempo API. It's standardized by ISO. And as long as it returns this format, you should be able to construct a Tempo type from this. Should it directly return a Tempo type? Probably. I mean, these libraries are written in JavaScript for JavaScript applications, right? So given that Tempo is the sort of future of Dates and Times in JavaScript, it makes sense that they could return Tempo types. I guess I could fork all these libraries and make versions of them that do this and make that become really popular. Or some of you could do it. That would be fun as well. There are already many that you can pick from. I went to NPM quickly and found out too. So there's React Types and Pickers. If you're using React, there's DateTimePickers if you're using jQuery, or nothing at all, which, I mean, it's just less so, but still jQuery. And yeah, you can drop any of these in. It could return an iso601 type, and you can use this string to construct a plain DateTime object in temporal. So temporal is the namespace. On the global, you can say temporal.plainDateTime.from, which is a static constructor method. It's a factory method. It takes in a convenient string format and pretends a plain DateTime object.

So once you have two plain DateTime objects right here, you're making an invoicing application. So you at least need two, a starting point and an ending point. So now that you have two DateTimes, you can find the difference between the two DateTimes. You can find out how much it worked.

When you have a starting point and an ending point, you can find the difference by difference methods. And as we talked about, it's arithmetic. So the answer would be a duration.

Now, one key caveat that I want to talk about, one thing that you should note here is that durations can be both positive and negative. And the direction is important, especially when you're adding a number of durations. If you're adding 50 durations, then one of them is accidentally negative, and then you're not going to notice that the answer is a little off, and you end up charging less money, which you don't want to lose money, especially when you're dealing with money.

You should make sure that you can check the sign, the duration dot sign. Dot sign is a getter. And you can also find just the value. So whatever the sign is, it will return a positive result.

So let's see here. In this code example, we have two play date times. We have earlier, which is well, earlier. It's at midnight, and we have later, which is the same day, but four o'clock. So it's later. And just to notice the directionality here, there's two ways to find the difference.

There's later dot since earlier. So here later is the receiver, and earlier is the parameter, right? Because it's been X hours since earlier. And that would give you, you can put in what is the largest you want and the output, and it would give you a duration with four hours. Or you can say until. So because it's until, it means it's until later, right? So the sign reverses. This time earlier is the receiver, and this time we just said minutes. So it would give me 24 minutes, which is also four hours. If you change the objects, if you say later until earlier, it would be a negative result. We don't want a negative result because we did not work negative four hours.

And then once you have all these durations, you can find out how much it worked. Because you have an array of durations, you can add them all up. My friends who like functional programming, clean code might try a reduced method. I'm more sloppy. I tend to write code that looks like this.

So you can just have a for each loop or sort of a reduced method. One thing to see here is that we created zero durations using two different ways. So, in one, we just constructed a new temporal duration object. And in the second, we used the from method that we talked about from last time. If you notice here, I've used a spring format for the duration, pt 0s. And that was also sort of referred to in the last slides.

Let's talk about it in just a bit. But remember to call absolute if you say total.add duration.absolute, that just ignores the sign, which is something we probably need to do, right? To talk about this duration serialization format that I just talked about, durations can be a number of units, right? A duration could be one year, two months, three weeks. And all this duration can be represented in a spring by this persistence format. So it's P1Y2M. So if you see the pattern here, it's P, which is constant. It stands for period, if you're curious. So, period, one year, two months, 1Y2M, 3W for three weeks, four days. Then there's a T for time, and then five hours, six minutes, seven seconds, so on. One thing to note here is that this format can use fractions, so you can say something, you could totally say something like 2.5 months. But do keep in mind that it's probably a bit problematic because, so if you use the template polyfill, that I'm going to talk about in just a bit, it's written in JavaScript. JavaScript does not handle these numbers really well, because it is IEEE floats. Some of these fractions cannot be actually represented in JavaScript. So if you're using fraction, probably stick to these objects. But if you want, you can use the trim format.

So now that you have the duration, you can charge money by the hour, depending on the contract, actually, you might want to charge per day, per hour, per month, whatever the contract is, really. The math is easy. The math is so easy, in fact, that it's both inter-temporal. For all these related mathematical operations where you have a big duration and you want to bring it down to a single unit, you can just use the total method. So let's see here. I'm a widow who calculates the time I've worked in one, the second duration. So if I work a total of a million seconds, it actually just means that you can see I used the total method here to say that I want all this in unit hours, and it would give me 277.7. So that's how much I work. That's not a lot, but I like to calculate that in seconds. So once you have that, one last thing that I want you to remember is that relativity is important.

We talked about things like 2.5 months. Now 2.5, what's the meaning of 0.5 months, or even one month? It's really relative to what you're talking about. Right now, one month might mean 31 days. In February, one month might mean 28 days.

So, you know, an example would be that we can have a duration that has 2756 hours. And if you take that total, related to two different times, right? It's actually the same point in time. It's in this case it is 1st of January 2020 midnight, it's also 1st of January 2020 midnight here. But in this one, it is in the timezone Europe slash Rome, which, as you know, it's a real time zone that does the daylight savings. So, in this case, the number of months that have passed is slightly less. So, because they didn't have the daylight savings here, they didn't have the daylight savings here. So, some of these things do make sense, given relative to what we're talking about.

A quick example could be that in many places, if you take an unpaid vacation day off, you get paid a constant amount of money for every month, irrespective of how many days there were. But if we take a single unpaid day off, let's say, the money that they pay you less is actually dependent on the number of days that there were in that month. So, taking an unpaid day off in July is technically much cheaper than taking one in February. So, all these things, of course, need to be taken into account. That's why you can use relative to provide exactly the what you were up to.

And next off you have rounding. So, now that we have all these things, the final value can just be rounded up or down depending on what contract we're talking about. But sometimes you don't charge by a single unit, right? You don't charge by every hour or every day, but you charge by a number of Xs, right? A number of days and a number of hours. And, if you think about it, charging by the day is technically that, right? When I say I charge per day, that means that I charge per eight hours. That doesn't mean that I'm talking about charging for 24 hour checks. So, this gives you a sort of more powerful method called round. And, unlike total, you can do more fun things with it. So, let's say that I had a six minute appointment with an immigration lawyer, and the immigration lawyer actually charges per every five minutes, and of course, they round up. So, if I spend six minutes with them, actually, I need to pay them double the amount if I just talked a little faster, which is why I should talk faster now. But, that's all fun stuff. We talked a lot. I had a lot of fun, but now it's time to do something that's more practical. So, I'm pretty sure a few of you had your phones out, but if you scan that QR code, I can show you that for a bit more, you will find this sandbox that I made for you. And this is the fun stuff, right? The code sandbox is actually about a job application so you can fill stuff up like the date of birth and where you work from and where to.

And it calculates a bunch of stuff. It's just an example. But the fun stuff is the calculate age method on this one is written using the moment API. The calculate time to interview is written using the Luxon API. And calculate job experiences is written using plain old date. And your job now is to actually rewrite all these methods.

There's links to the docs all over the place. And you need to follow the comments. And you need to forward this sandbox and write the code using tempo. Maybe you can just comment it out and see the new code. But you'd see a bigger improvement. And you'd see less code. And you'd see code that makes more sense to you, hopefully. But yeah, I'd love to see what solutions you've come up with for these.

So let's quickly go back to my slides. Okay. My slides. Let's quickly go back to this. Okay. So you can scan that. And if I'm there, I'll probably just paste the link to the chat. And quickly links to the future and present, I'd send you links to these slides as well. So you can click around these. Here's a link to the polyfill. We're using this polyfill also in the poke sandbox. So this is a polyfill that we came up with that can poke champions. It's sort of a reference implementation and it works. It should be, it should work in production as well. So you can follow that. There's a issue on V8 for, for Vent10 with LAN in Chromium and Chrome and Edge and all your favorite browsers.

And also Spiderman 3 for Firefox, which is my favorite browser. And you can keep refreshing these JavaScript core if you like Safari. And I try to refresh them every five minutes to see if there's any progress.

But there is a repository for Temporal V2 for all the new ideas that we're coming up with for sort of a future extension to this. And just quickly need to thank a bunch of people. I want to thank the Temporal Champions for working on all these special things. The Moments.js maintainers for kick-starting the original proposal. And the organizers in PC for inviting me and for facilitating this entire event. And Oga for helping me build the code sandbox. Thank you, everyone. But last but not least, thank you.