Hasty Treat - Temporal Date Objects in JavaScript

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, Node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest web development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott

Welcome to syntax in this Monday. Hasty treat. We're gonna be taking some time to talk about time, and I'm talking about the brand new daytime stuff in JavaScript.

This is really, really fascinating and a huge topic. So we're gonna be getting deep into this stuff, and I'm referring to the temporal proposal for JavaScript.

This is currently in stage 2, and we have a whole lot to say about this. Before we do so, though, let's introduce ourselves. My name is Scott Tolinski. I'm a developer from Denver, Colorado. And with me, as always, is the Wes Bos.

Hey, everybody.

Hey, Wes. Wes and Kit. He's got his, son Kit on his lap here, and it's, it's fantastic. I love it. Yeah. He's being quiet for now, so I'm just trying to play some Arthur without sound. Fantastic. What a Man, can we just say that Arthur's the best show ever? I love Arthur growing up. Do you watch it? Yeah. I used to watch it before school. I absolutely love Arthur. That Aardvark man. Yeah. He's a he's a champion.

So good. This episode is sponsored by another champion in our industry, and that is Sanity at century.i0.

Now Sentry is the perfect place to keep track of all of your errors and exceptions.

Since we're gonna be talking about JavaScript dates, imagine this. You write some JavaScript date code and something breaks, and you're you're trying to figure it out because the JavaScript current data APIs is is very difficult to work with. Or maybe you've brought in some third party library, and that's caused more issues. Well, Sentry's here to help because it's the perfect place to log all of your errors and exceptions, track them, and find them in your application to fix them. You can then select it. You can create a GitHub issue. You can mark it as resolved. You can mark it as ignored, but you can see exactly how many people this particular error is affecting. Maybe you, were trying to work with time zones, which is something that's Node notoriously difficult. And you goof something up, and now somebody on the other side of the world is having a bug due to your ignorance and the problems in the date API with JavaScript. Well, Sentry is there to help. So if you wanna give it a try, test out Sanity at century.io.

Use the coupon code taste tree, all lowercase, and all one word. You'll get 2 months for free.

So let's get into it. We're talking about the temporal API, the temporal proposal.

There was a link in the proposal. First of all, we're we're we're linking the proposal in the show notes here, so please click on that. But did you see this, maggiepaint.com link? It was called fixing JavaScript date. This was a really great blog post. And if you want a little bit of background in on some of this stuff, I would pause through this blog post too because she goes into some of the problems here. Like, what are what are the problems with JavaScript date? Well, no support for time zones.

Parser behavior is unreliable. The date object is mutable. There's a lot of, like, little issues here, and it just goes through and talks about why the JavaScript the date API sucks.

Yeah.

Yeah. It's like I was just going through this whole proposal, and, by the way, it's massive. Massive. Like, there's so many different parts to it.

Hey. What's up, kid?

Basically, I'm saying it's a wicked awesome API for working with dates and times and relative time zones and durations and, basically, anything to work with time or dates or calendars and be able to convert them to different types of calendars and different types of time zones and not get anything lost in between there. So I assume once this is shipped to the browser, we'll do away with like, it'll it'll obviously still be there, but, like, the whole new date will just be, like, deprecated, and we'll use the new temporal, which is a capital t temporal global namespace, in all of our JavaScript.

Which is very cool. You know, it's great that there's this big problem that we all know because we know it's a problem because I mean, how many times have you done a JavaScript project and not reached for something like date f n s or moment ESLint the past? Like, me, never. I pretty much though, that's like a day 1 install for me in terms of, like, libraries that I'm interested in using. DatefNS right now is is always going to be something I'm going to use. So the fact that there are people out there who are doing something about this rather than just authoring a library and say, you know what? We can fix the JavaScript date by introducing this new temporal proposal.

And one neat thing here is that it's, polyfilled as well. It says the polyfill specification documentation Yarn under continuing development. It should be understood as unstable.

So with that in mind, it's neat that you can actually use the poly fill today and at least try these things out to have a handle on them. And I always love that when when that exists so that we're not just gonna be drop this brand new date thing in our laps and been like, alright. Now it's now it's the new new. We're gonna have the ability to polyfill it. It's true. Like, we can both test it now. And, also, like, what's really cool about that is

once this thing drops, if you read the read me, it that they are very close to going into stage 3, at which point it will be considerably harder to add and remove stuff. So, like, maybe in, like, what, like, a year or a year 2 years, we'll have this, and then we can just start using it because we'll have a polyfill. We can drop that polyfill in and and just go nuts. It's not it's not one of these things where we have to wait for all the browsers to support it because it's it's easily

supported. Sorry. He's being lied. Node. He's fine. I think the moment that said stage 3 is the moment when I would consider to start to to drop this in with a polyfill and try it out and use it over a library because you won't have to bring in a library to do date manipulation stuff in the way that we were before. So the the principles here are that all temporal objects are immutable.

So, that's fantastic bringing some immutability there.

Date values can be represented in a local calendar system, but they should be convertible to and from the Gregorian calendar.

Well, it's the proleptic Gregorian calendar, which I I'm not familiar with, but I I'm just What is that? I'm sure it's important. It's a link to Wikipedia. Let me see the Proleptic Gregorian calendar. Oh. That's the calendar that we use. Is ESLint Canada and the US? It's just the Gregorian calendar. It's just the fancier name for it. Yeah. Very nice. Very nice. And it's also all daytime values are based on the standard 24 hour clock, and leap seconds are not represented. So there's no leap seconds, which are leap seconds in the current Node? I'm not pause I don't know anything about leap seconds. It's not anything I've ever thought of. It says in the pnpm, as regular Java as JavaScript is now, it does not account for leap seconds, but it does account for leap years. Yeah. This spec is absolutely massive, but there's some really neat stuff in here. So if you do go to the GitHub page for this, at the very bottom in the documentation section, there's a a cookbook to help you get started learning the ins and outs of tempura is available here. And if you select that, it takes you to a neat little, cookbook documentation, which allows you to see in, like, FAQ frequently asked questions, but also, like, really standard stuff. Here's how to convert between, particular types, converting between temporal dates and legacy dates, serialization, sorting, rounding, time zone conversion, arithmetic with dates.

So what does the syntax look like this? You mentioned that it's a capital t temporal, but you couldn't think of it as like temporal Scott now dot date, date.string, whatever.

But from then Wes have temporal.now.instant.

There's a whole lot of different classes inside of here, and it seems all very nice. I I don't know if I have any. Like, I haven't obviously used this at all, but just by looking at it, it seems like the kind of stuff that you'd expect from having a a library. Yeah. Like, you you know, like, when you have a date object in JavaScript, and you wanna grab, like, the month,

and you also wanna grab, the number of milliseconds or, like, the day of the week, and you gotta remember if it's offset by if it's 0 based or if it's not. Like, I think days of the week are 0 based, whereas days of the month are not. Like what? Yes. Oh my god. That is the worst.

This is just a really nice API that has, like, properties. You can just say, like, Scott minute. So you take your date and access the dot minute or dot date or anything like that. There's this temporal instance Scott already mentioned that is the pretty much just like day dot now. That's a, nano actually, it's nanosecond representation of a fixed point in time, whereas I think data now is just milliseconds. Milliseconds from sometime in 1970 or something.

Yeah. January 1st midnight, January 1, 1970, that's when time was created.

So I guess we get nanoseconds now, which gives us, even even more down to to the wire, which is pretty cool. And then those those instances, just like Unix time stamps are right now, is they can you can move that anywhere. And regardless of time zone or calendar or anything, that can always be that is just a time. Whereas, like, if you were to use, like, January 5, 2007 at 8 AM, you will go, like, okay. But which time zone? Right? So instance are across the board the same.

And there's just so much stuff in here. I I I just have this open and just pulling through all the different properties. I think I'm gonna have to spend some major, major time on this. I think it's just one of those things that's going to eventually just replace the way that we entirely do JavaScript dates in our applications,

and I am here for it. It's it's cool because you can like, the calendar API is just something we don't have in JavaScript at all. You can make a new calendar. You pass it a date, and then from that, you can ask what year it is, what month it is, how many days are in that current month, what day of the week is it. One thing I'm wondering is, can you get and I'm assuming you can, is can you get a list of all the weekdays and months of the year? That's one thing I've I've never been able to do. There was, like, a trick you can do in in JavaScript that I figured out one time, but I really wanted to be able to just, like just give me an array of all of the months of the year so I can loop over them and put them in a drop down or something like that. And I bet there's something in here like this. The the there's probably

there's probably, like, 200 methods in this entire spec for different things, so it's massive. It's massive. And, yeah, that's what I'm saying. I'm just, like, clicking through this nonstop and and finding neat things. And it is funny that you mentioned that, like, building, like, date pickers. One of the reasons why date pickers are really terrible is because of things like, this, like you mentioned, having to create an array with all of the month names and whatever. It's like, why can't I just get that information from JavaScript itself in an easy way that JS, predictable? I don't know if you you've worked too much with that calendar. There's, like, a React project, React big calendar that was it's really super cool React component for building calendar stuff. I worked with them pretty heavily in that Node startup I was working for, and I just remember just fighting that library.

I had to build my own, like, extended version of it. I remember fighting that library, how dates worked in JavaScript, and everything just felt, like, just insurmountably annoying. Just like, come on. This JS, like, the worst worst thing I'm I'm doing in my day to day Bos. So Wes.

What else we have? We have durations.

So if you have, like, 4 days and you say, oh, I need to add a day to that, there's dot add and subtract methods from durations. And then I'm assuming you can take that duration and then add and subtract that from a specific date much like date functions will allow you to do, which is really cool. So you can just maintain this running unit that's not a number. It's literally a duration.

This is, this recipes thing is, like, really super good. If you haven't popped up in the recipes one, schedule a reminder ahead of a matching a record setting duration, push back a launch date. And Sanity, like, actually gives you code to show you how if you need to push back a launch date, here's how you write that code using this new temporal. And to me, this is the most interesting aspect of all of these docs because this shows what real practical code is gonna look like. Flight arrival, departure, duration. So you you can get the instance from the incident like, there's a a difference method.

Gosh. You get the difference in hours, and it gives you the difference in hours. Look. Imagine that. It's just it's very cool.

One other really kinda neat thing I saw saw in here, and I I hadn't even thought of this, JS, temporal dot year month and temporal dot month day. And this allows you to specify a month of a year and a a day of a month without having to actually make a date for it. And I thought that was kind of interesting because, like like, for me, when I do my affiliates, I have, like, affiliates earned in February 2020.

And then, like, I have to represent February in, like, a specific date. Right? And, like, you just, like, okay. Well, I could I could choose, like, February 1st at 12 o'clock, but then in some time zones, that's January 31st.

And So you just do it for your own? Node time zone? Yeah. Right. Right. And then you hope yeah. And it's just like, oh, well, like, why do I have to set a time for the rest of this? I just wanna say the month and the Yarn. And they have a good example of, like, the November 2010 meeting or, the 14th July Wes, like, you just wanna specify a day or a month, and this will allow you to do that. And then you can then go ahead and translate that to other ways you wanna represent it in different types of calendars.

Mhmm. Yeah. I am very much looking forward to that exact thing. Sometimes I like I'll I'll do to my, like, my, sales manager. It's It's not Node a human being. My sales manager dashboard that I built that shows, you know, my graphs and stuff and all. And that's, like, the worst part about anything. I Scott to set. You gotta create your date, then set the time to 0, and then you gotta take the other day and send it to the the last day of the month, the end of the day. Make sure you ESLint that Node, and then just, like,

yeah.

My my own sales dashboard right now, if I travel, it's off by however many hours. Same. Mine might as well. And I I'm like, I should fix that, and I never do because I go Node, and it it it's fixed when I go home. Yeah. Right. Exactly. You can always just spoof the location or something if you wanna get the right ones because it's I mean, yeah, I mean, if you're the only person looking, it's not like you got a 100 people looking at it or something. Yeah.

So good. I think that's it. I'm gonna try out this polyfill because it's obviously not done. Don't put it in your app yet. But I'm gonna put it in my app. Pushing it right now. Of course.

Do it. That's that actually happened with, date functions 2 point o. I, like, I just put the beta into production, and then it released. And I broke because, like, uppercase y was not lower. But they had it. They caught it in their warning message, which I was super happy about. Me too. I know. I was very happy about that. That was a fun conversion.

So that's really all I have on this. You got anything else, or or is that I love this. It's so That's it for me. Visual. You gotta see these code examples. So read this blog post, fixing the JavaScript date. It's from 2017, then check out the proposal, then check out some of those recipes.

We'll link all of that stuff in the show notes. These recipes are really super good to check out. This is the new temporal proposal, so it's stage 2. It's not quite in. It's still possible to change, but it looks like it's moving full speed ahead.

And hopefully, we get that in soon. So that's all we have for this Sanity treat. We'll be back on Monday or Wednesday. What are we doing on I had so much time to think about that, and I still goofed it up. We will be back on Wednesday with some spooky web dev stories again. We even might have a guest,

reading a spooky story for us. You gotta listen to this one. It's gonna be a banger. Must watch. Listen not watch. Thanks again for tuning in, and catch you later. Peace. Peace.

Head on over to syntax. F m for a full archive of all of our shows, and don't forget to subscribe in your podcast player or drop a review if you like this show.