They explore the current flaws and issues in JavaScript that make the Date object so hard to work with, how libraries like Moment.js helped but eventually became too complex themselves, and why the Temporal proposal took nine years to complete.
Temporal is a new TC39 proposed standard for JavaScript that replaces the Date object. It operates as a top-level namespace and brings a modern date/time API to the ECMAScript language.
Connect with Jason on Bluesky or at his website.
Congrats to Great Answer badge winner BrenBarn, who won the badge for their answer to rethrowing python exception. Which to catch?.
TRANSCRIPT
[Intro Music]
Ryan Donovan: Hello everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we're talking about time, JavaScript, and the Temporal proposal that is looking to be incorporated. My guest for that is Jason Williams, senior software engineer at Bloomberg and the creator of Boa, a Rust-based JavaScript engine. So, welcome to the show, Jason.
Jason Williams: Hey, yeah, thanks for having me.
Ryan Donovan: My pleasure. My pleasure. So, before we get into talking about time, give us a little insight into how you got into software and technology.
Jason Williams: Yeah, so I've been a software engineer myself for quite a while, probably over 15 years. Could probably come up to 20 years, now. I've been at Bloomberg for around seven years. Before that, I was at the BBC, a broadcaster in the UK, as a senior software engineer working on the BBC sounds product. And yeah, even going further back than that, I was involved in some open-source projects. I was actually trying to find one of my earliest contributions, and I think it might have been jQuery back when John Resig was running the show, and it was around 2010, and I think I was trying to fix a bug with click events. And Interesting, it's related to this actually, because when I was going back and looking through that book and the conversations. So, obviously, it predates GitHub a little bit, but you still have the comments when somebody did a patch and all of that.
Ryan Donovan: Right.
Jason Williams: And actually, one of the people who commented is someone who is a Temporal champion. So, it's a small world.
Ryan Donovan: Yeah. I keep seeing this being talked about. And in your blog post about it, you mentioned it's taken nine years to get this moving. First of all, I wanna talk about it: why is time—date and time—so difficult?
Jason Williams: Yeah, that's a good question. I think there are so many approaches that people can take. And I also think it depends on your audience and who's using it, as well. For instance, when JavaScript first started out, back when Brendan Eich was working on his sort of prototype of what we now know of as JavaScript. I think then it was quite easy to just take something quite basic, take something off the shelf. He probably didn't foresee that we were gonna end up with these huge JavaScript applications that needed to know things like time zones, or calendars, or anything like that. I think back then it was like, 'hey, here's a basic date object,' and that will do.
Ryan Donovan: And he knocked out the precursor to JavaScript in 10 days. A 10-day sprint.
Jason Williams: Yeah, that's right. And I guess a lot of that was because he was able to just take what Java's APIs were doing and do a wholesale port over into JavaScript. So, that made life a lot easier. They didn't have to sit around and come up with API design. It was, ' let's just take these things.'
Ryan Donovan: Yeah. So, date and time [are] things that people take for granted, as like, it just works, right? But we've had a conversation on this program with Jon Skeet about how complicated it is. And we've obviously had the Y2K issue, and we may be coming up on the apocalypse with the Linux State and time. But I remember at my last job, people sitting up when there was a time zone change, when there was a daylight savings change, just making sure everything went correctly. And you talk about a lot of the little things that you would expect to work correctly that just don't. Are these things that you think showed their wear and tear because JavaScript became more of an enterprise language?
Jason Williams: Yeah. One of the things that I mentioned in the blog post is how the web grew up. But the date object [in] JavaScript stayed the same. I think there's definitely an element of that. One of the biggest flaws, I guess, most people would describe in date is the mutability factor of it. I think if you go back, I dunno, 20 years ago, some small applications hit that bug, but it wasn't really deemed as a big deal then. A lot of things were mutable, a lot of applications running JavaScript are only doing very small changes to a website, changing the color, or reacting to a click input. And then, I guess as we started, it hit the sort of corporate world as these applications got bigger, and were used a lot more places. These bugs that started off being trivial were actually quite important, and [were] causing a lot of problems.
Ryan Donovan: And I feel like the date being mutable is one of those bugs that you don't really understand until you run into it.
Jason Williams: Yeah.
Ryan Donovan: Can you give an example of what this looks like in practice?
Jason Williams: Yeah. So, the API of getting and setting a date is: you have a date object, and if you wanted to, say, get the day, that is just calling the day object, 'dot. Get date,' which is not the best name in my opinion. I think that's another issue with the date object. The name's a bit vague. It's not really clear what sort of type that's giving you back. But setting, you can also have 'set date,' as well. So, you have ‘get date’ and ‘set date.’ You have a lot of pairs like this. And what people tend to do is, when they want to return a new day of that date, they often call 'set date' and then pass in 'get date +1,' or +2, or whatever, or -1, and then return that value. But 'set date' will also mutate the current date. So, people often ended up trying to return the new date, but also setting the current date that was passed in. So, you ended up doing two things. You were giving back a new date, but also setting the current one, and that's the trap that a lot of people often fell into.
Ryan Donovan: If you wanted to calculate something for a future date, you'd accidentally change–
Jason Williams: Yeah, exactly. Yes.
Ryan Donovan: It's cheap time travel, right?
Jason Williams: Yeah. Exactly. So, a lot of these things change in place. I think if you look at JavaScript today, a lot of newer APIs, and a lot of newer proposals don't tend to do that as much. You'll probably notice that, these days, things that change in place is quite rare.
Ryan Donovan: When people started noticing this, a lot of the sort of fix for it came through libraries. Can you talk about how that worked, and what're the sort of flaws in that approach?
Jason Williams: Yeah, so I think once we reached that era when– so Node.js was born in around 2009, and then we started seeing things like NPM, and not just NPM no, but people just sharing scripts. I can remember adding script tags to the top of your page from random SourceForge endpoints or wherever. But we started to see libraries tackle this. I think Moment.js was certainly the biggest example, and I think it went out because, one, it was one of the earliest, but also because the API was quite straightforward. People understood it. It made sense. They had good documentation quite early on. So, most newcomers were able to come to Moment.js' website and understand what these things are doing. So, it took off in a big way. I think, actually, Moment also gave you the idea of these sort of types, as well. If you call this, you are gonna get this sort of value back, and then with that value you can do these things. The problem though, started to, I guess become more apparent when websites were becoming a bit more bloated, and it wasn't just Moment.js, to be fair. Once you went from around 2009 to 2016, 2017, you did start to see more and more libraries become quite huge. And Moment had a lot of data packed in with it. So, it needed locales because it did date formatting. So, taking a particular date, and formatting it to a certain locale. But also, time zone information as well is something that Moment.js supports. To be fair to Moment, I think they offered a way to strip it out if you weren't gonna do any sort of datetime arithmetic against various time zones. But a lot of people did use that. So, we started to see huge sizes in these datetime libraries. Moment was one of them, but you had other libraries that were also doing the same thing. And these sizes were massive. You could cheese at these libraries down to 150, 200K. But that was still a big chunk that people were having to download all the time when using those various apps that were using Moment.js.
Ryan Donovan: And for a lot of places [that] have slower internet still, that 150-200 K is a pretty big lift, right?
Jason Williams: Yeah, absolutely. And developers were raising this on Moment.js as a GitHub repository. Is there anything we can do about the size? I think Maggie Johnson-Pint, who was one of the maintainers of Moment.js, among others. I think I recall her going to some conferences, and one of the first questions that people would raise to her was, 'how can we bring down the size? We love Moment.js, it's a great API, but it's just way too big. We can't really be shipping this all the time.' And so, I think, yeah, there's only so much that you can tree shake.
Ryan Donovan: Yeah.
Jason Williams: They don't know ahead of time what time zones or locales people are gonna need or use. So, I think that's when Maggie tried to see if we could standardize this. Browsers have this information anyway. Time zone information browsers have, and also locale information. There's a lot of internationalization supporting browsers these days. So, I think by the time you got to around 2017, it made sense to start looking into a way of getting this information outta the browser rather than shipping it via a JavaScript library.
Ryan Donovan: Right, and incorporating it into whatever the client program is, right?
Jason Williams: Yeah, exactly. So, having an API design that works that people can use. Having something that works in V8, the JavaScript engine that Powers Chrome, because then, that can also be used in, say, Node.js. So, anyone who's using this software server-side, or not even in the browser, this would still work.
Ryan Donovan: Yeah. So, you've obviously got involved in this because you've created a Rust-based JavaScript engine. How did you go from implementing to be like, we need to make some changes to JavaScript itself?
Jason Williams: I think the two sort of happened in parallel. So, a long time ago, I was interested in working on Servo. So, Servo is an experimental rendering engine written in Rust that was maintained by Mozilla at the time. That was actually probably one of the first ever Rust projects. It came out not too long after the Rust Programming language was made known to the world. I was really interested in learning Rust, but I was also interested in learning how browsers work. I was a front-end developer at the time, and anything that I could understand about rendering performance and making websites faster was a huge bonus to me. I worked on Servo for a bit and contributed to that. I really wanted to see a JavaScript engine made in Rust as well, because I saw how Rust was improving a lot of software. So, the CSS engine, for instance, in Firefox today is called Stylo. It is entirely in Rust, and I was around when that was being built, and seeing how much faster that made things was inspiring. And so, that's where Boa took off, which was to try and see if we could do the same thing for JavaScript. I would say around the same time this was going on, I was also working for the BBC, and we really wanted to improve Promises. So, we were using Promises quite a lot in JavaScript, and we wanted to know when some Promises have failed, and some have been successful. So, that was when I had an opportunity to go to TC 39, who were in London at that time – they had their plenary in London, and tried to see if we could push forward a new proposal. And that's where Promise.allSettled() came from, which is now available in the standard, and it's in all JavaScript engines. I guess from there, I had a bit of a foot in the door. I was already talking to some people in the committee. And then a year later, I joined Bloomberg. So, in 2019, I joined Bloomberg as a software engineer. I was still working on web, so I was working on one of the websites, and that's when we had some discussions internally. I learned that Bloomberg are very interested in Temporal. It had only just started around that time. I think it may have been either stage one or just reached stage two. I guess after the work on all settled had finished, 'cause that was stage four at this point; so, it was like, 'okay, success, it's done.' I was approached and asked if I would like to take a look at Temporal and if that's something that I could help out with. And I was like, absolutely. I would love to jump in on that and see what we can do. And so, yeah that's around the time. 2019 was when I got involved in Temporal.
Ryan Donovan: Right.
Jason Williams: And yeah, started being a champion on that.
Ryan Donovan: Yeah, you already have the in, the expertise. You can be their man on the inside, right?
Jason Williams: Yeah, exactly. In terms of Boa's involvement with that– so, a couple of years, I guess, jumping ahead a little bit. By this point, I should probably explain Boa was no longer just myself. When Boa started, it was just me. Fast forward a few years into the future, we have a maintainer team. We have five people working on it fully, and then we have another set of people who come and go, and add features here and there. One of the maintainers in Boa was really interested in trying to build Temporal into Boa, which of course, I was happy to help them out with that and see what I could do. And of course, I was in the Champions group.
Ryan Donovan: Right.
Jason Williams: So, I invited them into the Champions group. I introduced them to everyone else and said, 'hey, we have someone from Boa who would like to try and build tempo.' And that ended up being really valuable because they were able to provide feedback. They were able to try out new implementations. So, it was another perspective as well, the champions, to try something else that could run Temporal, and not just one engine, but now we have two. And then, yeah, over the years, that improved. They built a good relationship as well with the champions. And then, we managed to get another implementation in Boa for Temple, as well.
Ryan Donovan: I want to talk about the length of time it's been taking. It's been nine years since start to almost adoption? I don't know if it's adopted yet, but it also sounds like over this course of time, you've been implementing it, so it's been part of the Boa engine, is that right?
Jason Williams: Yeah, that's right. Yeah, so nine years is correct, yeah.
Ryan Donovan: So, why does something like this take nine years to get implemented?
Jason Williams: Okay, implemented, or specked, or both?
Ryan Donovan: To get to whatever, the stage four, whatever, the final–
Jason Williams: Sure. So, normally, I should probably say that most proposals do not take nine years. This, even within TC 39 realm, is, I would say, quite abnormal. But at the same time, I think everybody understands that this has a huge API surface. Even if any of you have perused the Temporal documentation, you can probably see how big it is in terms of API space. Most proposals in TC 39 are quite scoped, quite small, and are able to get clear reviews and agreements as it goes along the stages process. I would argue Temporal was a little bit different because when Maggie proposed it back in 2017, there wasn't a clear idea on the API at that point, and that's okay. H0, stage one, that's fine. It's just talking about the problem space.
Ryan Donovan: Right.
Jason Williams: Everyone agreed that we needed a new daytime library then, so we can always iron out what the API looks like later on. Not a problem. Stage two comes along, and discussing what the API looks like is always gonna take longer in Temporal than maybe other proposals, simply because the API is just bigger. So, when it comes to things like, do we want to show it a datetime? Okay. Should it have a time zone in it by default, or should it not have a time zone by default? That those sort of questions, do we have instance? Do we not have instance? How should they look when you try to display them? So, if you call two string on one of these objects, how should it be represented? So, those sort of questions can take a long time, and not everybody agrees, of course, either. Some people think it should be how Java do it, other people think it should be how another ecosystem does it. So, those discussions go on. Once you get an idea of the API, we reached stage three. I can't remember off the top of my head what year that was, but it was probably around 2019-2020, and then we needed to start writing tests, and making sure that the API we have actually works. I would argue that that itself took quite a long time. Temporal has four and a half thousand tests.
Ryan Donovan: Wow.
Jason Williams: And just to put that into perspective, date has around 500. So, it has more tests than I think any other built-in in the JavaScript language because of the API Surface area. But also, we had to implement it, as well. So, not really the final stage, but we needed to get this into engines, and that's when we realized that actually it was probably too big. The API was, yeah– we had to remove features from Temporal. So, things like custom time zones, custom calendars, the size of Temploral was just too big. And that was actually a concern. V8, for instance, ship Chromium to lightweight devices, lightweight Android mobile devices, and they need to make sure they have a small footprint. So, we were very conscious of not bloating the JavaScript engines too much. And so, discussions like that alone were like about a year or so. And then finally, just one more thing. We also needed to make sure that serializing these objects worked, and we were using ISO 8601 for that. And even that didn't support zone datetime objects, which I can explain in a bit. So, we had to work with IETF to try and make sure that ISO 8601 needed to be updated. And that itself is also a two-year job. So, it spreads out into all these different areas and all these different standards bodies, as well. Yeah. It's a big proposal.
Ryan Donovan: Yeah, it sounds like it touches such a fundamental part of existence. Even within, without software engineering. So, now let's do the big reveal. Let's talk about what Temporal actually does.
Jason Williams: Yeah.
Ryan Donovan: What's the difference between the previous date? Let's just start there. Yeah.
Jason Williams: Yeah. So, Temporal is a datetime API. It's a datetime library built directly into the language, directly into JavaScript. You don't need to import it, you don't need to download it from anywhere. You'll just have this in any JavaScript environment that you're using. It provides a comprehensive set of types that allow you to work with dates and times, so that you shouldn't fall into bugs that many people have been falling into with dates. So, earlier we were talking about date being mutable, and calculations on date might not land you in the right place. For instance, jumping forward a month in date can be tricky. So, what Temporal does is it gives you a few types. So, one is 'zoned datetime.' I would say that's the most comprehensive type out of all of them. That gives you a lot of things built in. A zoned datetime is essentially just a datetime type that is always zoned to a time zone somewhere in the world. A lot of people obviously need this and make use of this. You want to convert time from one time zone to another. This type allows you to do that. You can pass in a time from London, whether it's via an offset, or whether it's via the IANA time zone string. And then, from there you can, for instance, add an hour or remove an hour, and you'll always land on a correct time. If you were to add an hour and there was a daylight savings jump, you wouldn't end up falling into a weird time. It would still land you at the correct time.
Ryan Donovan: Right.
Jason Williams: But also, you can pass in a new time zone, and it will put you on the right time there, as well. So, you don't need to worry about calculating times between time zones, it handles all of that for you. We have instance, which is similar to– I think the best way to describe instance is if you imagine an epoch, like how many milliseconds since 1970. An instant is essentially a wrapper around that, except we go down to nanoseconds. We actually cover nanosecond precision because some people were using nanoseconds. That is built in, that is supported, so you can store that in your database or whatever. Then, when you want to display that to a user, you can take that instance and say, 'display it in this time zone,' whether it's London, whether it's New York, and that will work. Funnily enough, I should probably say that when we were building out these types, we wanted to know what the biggest pain points were with date. So, we went to Stack Overflow, and you can filter by questions about dates, and that is exactly what we did. And the number one question was, 'how do I get an epoch in JavaScript?' People were a bit confused because it was the 'date get time.' Again, it's vague method names. People weren't sure what 'get time' gave you. So, we try to make our API a little bit more descriptive. So, with an instant object, you can say, 'get epoch milliseconds, get epoch nanoseconds, get epoch seconds,' and it's a little bit more obvious what that's doing. So, then after that, yeah, we have some other objects, as well. So, we have a plane date, we have plane time, plane datetime. I guess the comparison between those and the zoned datetime that I talked about is [that] these objects do not care about time zone. They do not care about where in the world it is. We describe these as a war clock time, so just imagine a clock on your wall. If you go forward an hour, that clock's gonna go forward an hour. That clock is not gonna think about, 'oh, what if there's a daylight savings transition?' And so, these are really useful if all you care about is just displaying that particular time. So, you create a time, and you display it. And people do this with dates. They take a time, put it into date, and display it. The problem though, is that date can sometimes change the time underneath you, and this actually happened with one of our champions who was trying to book a hotel, and when he got the confirmation page that the time was what he selected, the date was different. And that's because with the current date object, a lot of people call the method 'two local date string.' And what that does is it implicitly changes the dates to the user's current time zone, rather than the date that you put in there originally. So, playing datetimes are immutable. Once you've created a date, it does not change even if you try to format it for that user's location. So, these are really useful types, as well.
Ryan Donovan: So, this sort of makes me think of, what is a datetime object? Because I know in Linux it stores it as 'milliseconds since 1972,' or whatever. I could also see it stored as a year, day, month, whatever, down forever. And you have it down to nanoseconds. So, what is fundamentally that daytime object?
Jason Williams: As you mentioned in, in Linux it's 'milliseconds since epoch,' and actually, JavaScript is the same. The date object is 'milliseconds since epoch.' In Temporal, it's a similar structure. So, we do have time since epoch, it's just that we have nanosecond precision since epoch instead of milliseconds, which does mean that the size can be a little bit bigger because we do have to try and find ways to optimize and store that precision. The reason why we took that decision was because when we looked at how people are using datetime libraries, again, I guess coming back to Moment, but also looks on data fineness, Day.js, people do put nanosecond, precision timestamps in there. They're not always generated by the browser. They could be generated by an external source, but they have to then deal with them and display them to the user. So, that's one of the reasons why we chose that precision. But a datetime object, to answer your question, yeah, it's essentially that timestamp since epoch, but then, for the zone datetime objects, we can also store the time zone so that when we translate it back to a time it lands on the right time. And for a datetime object, it's pretty much dissimilar to how date is now.
Ryan Donovan: I know with the datetime in Linux, there's worries about the apocalypse, which I've mentioned.
Jason Williams: Is that the 2038?
Ryan Donovan: Yeah. 2038. It's gonna run outta space. A Y2K+. Did you consider that in the implementation?
Jason Williams: So, I remember we had discussions about it. JavaScript wouldn't really be affected. First of all, it's 64-bit numbers, 64-bit floats.
Ryan Donovan: Right.
Jason Williams: Actually, yeah. So, my understanding of the 2038 problem is we have the epoch stored in 32-bit integers, essentially. So, 32-bit operating systems, which should be far and few between now would be affected. I think anybody on a 64-bit operating system is fine because the epoch is stored in a 64-bit number. Dates, the instant objects in Temporal and some of the datetime objects – because we have to handle nanoseconds anyway, we use bigints for some of those objects. For instance we use big ins. So, those would not be impacted by the 2038 problem. And then, other types that don't need nanoseconds are 64-bit anyway. We don't have any 32-bit integers as a back in store for any of these types. So, my understanding is that we shouldn't be impacted by the 2038 problem. We should be able to just carry on as normal.
Ryan Donovan: Until you hit the 64-bit limit, which I assume would be 5,000 years.
Jason Williams: Yes. Yeah, I'm hoping that we have a solution by then. I think it's a few thousand years, is it okay? I think the 64-bit limit for an epoch is, yeah, it's 3000 years into the future. So, I think whoever's around then could sort it out. Don't quote me on that, but I'm pretty sure it's definitely outside of my lifetime. When it hits that, it will be someone else's problem.
Ryan Donovan: That's right. The AI overlords will have to worry about that, then.
Jason Williams: Yeah, but like I say, for instance, we use big int anyway. So, even if we did reach that point, and people are still using Temporal and JavaScript, instance should still work, I would hope.
Ryan Donovan: One thing I was curious about is why store the time zone date object instead of doing a sort of translation from a universal time?
Jason Williams: That is actually what we recommend people do. So, when we talk about instance, which is essentially just a wrapper around the epoch. We recommend people store the instant instead of a time zone object. So, like you just said, that is the universal time when something happens. And if you are building an application, and you are using Temporal for that application, I think even on our docs page or on the clickbook, we would recommend that you would serialize your instant time. That is what goes into your database. And then, on the way out when you want to display that to a user, assuming that user's time zone, we've made it very easy to translate an instant object to a local datetime. I think there's a ' with time zone' method. You can pass the user's time zone into there, and then that will give the local time. So, we don't really recommend storing local times, just as exactly as you mentioned, we would recommend storing the universal time.
Ryan Donovan: We're coming towards the end of Temporal's championing, but we're not quite there yet. What's left before this becomes standard operating procedure for everybody?
Jason Williams: Yeah, so Temporal is stage four. That's really good news. As far as TC 39 are concerned, it is approved, and everyone is quite happy with it in the spec. Where we are today is that it is in V8 thanks to the work of Temporal RS, which is the Rust Library for Temporal that V8 uses. It's in Firefox. Firefox have also landed this in May, 2025, last year. We are hoping to see this finish being implemented in Safari. So, in Safari you can use the tech preview, and that gives you access to Temporal, but it's still being worked on. I think it's around 60%, something like that. But we also now need to integrate with the rest of the web; it was not enough to just finish Temporal and then be like, great. Done. People actually need to use it in websites, right? So, things like date pickers, there's a way to get the date value from a date picker, from the HTML value. I think you can do value as dates, and that gives you a date objects. We are working with WHATWG to try to provide functionality to get a Temporal object out of there, so that people can just use date pickers natively and have Temporal objects. There's other parts of the web, as well. So, anywhere where you can pass a high-resolution timestamp right now, those types can come from dates, they can come from other areas, but we want to make sure that people can pass Temporal instance in those functions as well, and they're supported. Structured clone in JavaScript supports serializing types and copying them. We want to make sure that Temporal types are supported in there. So, it's basically going around the ecosystem within web, within the HTML spec, finding places where people are using date and making sure that Temporal is supported in those places, as well. And we are also doing that within Bloomberg, as well. I should mention that we also want to use this. This is something that, [at] Bloomberg, we're very excited about, and even for us, we want to make sure that we can start using Temporal objects instead of the old data objects. And we need to try and do that in a way that's backwards compatible, and we're not gonna break applications whilst making that transition.
Ryan Donovan: Yeah. I mean, it sounds like implementing this in the browser and the JavaScript engines is just half the battle.
Jason Williams: Yes.
Ryan Donovan: This is the old upgrade story where everybody was on Python 2 forever, and after Python 3 came out. Do you have plans to deprecate and archive the old date stuff? Or does the JavaScript coalition?
Jason Williams: Sadly not. There's just far too much usage of date today that we could realistically deprecate it or make it unavailable. I think what you may see are smaller runtimes that provide a much more sandboxed version of JavaScript. They may be able to afford to tell their users, 'you can no longer use date. You need to move on to this.' I think in the wider web, what you might see in future is we may encourage people to switch to date via, say, MDN and documentation like that. Because Temporal does cover everything that date does. So, in theory, you should not need to use date again, but we know that in being realistic, date is gonna be around for a long time. We can't just switch it off. All we can do is encourage people to use the new API.
Ryan Donovan: Yeah, get with the times, people. Update your dates.
Ryan Donovan: It's that time of the show where we shout out somebody who came onto Stack Overflow, dropped some knowledge, shared some curiosity, and earned themselves a badge. Today, we are shouting out the winner of a Great Answer Badge – somebody who dropped an answer that was so good, it got 100 points or more. Today, we are shouting out @BrenBarn for answering, 'rethrowing python exception. Which to catch?' So, if you're curious about the answer for that, we'll include it in the show notes, and we'll also include the question that the top datetime question that Jason pointed out. I'm Ryan Donovan. I edit the blog, host the podcast, here at Stack Overflow. If you want to suggest topics, share some comments, some feedback, email me at podcast@stackoverflow.com, and if you wanna reach out to me directly, you can find me on LinkedIn.
Jason Williams: I'm Jason Williams, Senior Software Engineer at Bloomberg and TC 39 delegate. You can find me on jason-williams.co.uk, and that website is also my handle on Blue Sky, so please reach out to me on Blue Sky with the same handle, and I'm always happy to chat.
Ryan Donovan: All right, thanks for listening, everyone, and we'll talk to you next time.