Brian Kardell: All right. Hi, I'm Brian Kardell and I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia. And today we're going to be talking about time with two of our fellow Igalians, Nic and Philip. So Nic, please introduce yourself first.
Nicolò Ribaudo: Hi, I'm Nic, Nicolò. I work on a bunch of TC39 stuff at Igalia. Mostly modules, but I'm pretty much involved in all of the proposals that we're doing.
Eric Meyer: And Philip.
Philip Chimento: Yeah. I'm Philip Chimento. I'm also an engineer at Igalia and I work also mostly on JavaScript standards and JavaScript engines.
Eric Meyer: And we have news.
Philip Chimento: We do indeed. Yesterday, at the time we're recording this, the Temporal proposal went to stage four in TC39.
Eric Meyer: Nice. Woo-hoo. But for those who might not be familiar with TC39, what does it mean to hit stage four?
Philip Chimento: So there's a whole staged process in TC39 for proposals before they actually become part of the JavaScript language. And it goes all the way from idea to design that's ready to be implemented. And stage four is the last one. It means that next year when they cut the JavaScript 2027 standard, Temporal's going to be part of it. And part of the requirements for that is that it's available in two major implementations.
Nicolò Ribaudo: It means stage four doesn't actually mean that people can use it, yet. Two implementations means that we have two browsers supported, but if you want to wait for it to be probably at least baseline so that it works across the latest version of major browsers, you're still going to have to wait for a while. You can very much play with it already if you are not targeting the whole web but maybe you're just running in some specific browser or specific service or runtime.
Eric Meyer: So you say at least two browsers. So stage four means we have two browsers. Which two browsers are those?
Philip Chimento: They're Firefox and Chrome.
Eric Meyer: Okay. And do we know what the status is with WebKit? Should that be coming?
Philip Chimento: Well, that's something that we have actually been working on at Igalia. Our coworker, Tim, did a whole bunch of it last year.
Brian Kardell: And some of it is in Safari Technology Preview now.
Philip Chimento: Yeah.
Brian Kardell: They do continue to merge things in, basically. I guess we could say that there are a whole series of pull requests that you have to go through because nobody wants one giant thing. Each one has to go through the process of getting merged, and I think there are maybe 40 left or something like that. It's a not small number left to go. So once those are all processed and merged, then the whole thing will be in Technology Preview. And then I imagine the next release will probably just contain the feature. And then it will be baseline newly available, at which point you can feel good about using it in limited contexts. Maybe not your main website, but if you have an app that you can feel pretty good that people are running on the latest browsers or you have intranet where you actually control that kind of thing, those would be great times to start using it. There's a polyfill, as well?
Philip Chimento: Actually, three polyfills that we know of. One is one that we've been working on. And we, I say a couple of people from Igalia and a couple of others from the ecosystem who have been involved in Temporal based on our research polyfill, which we use to write conformance tests for Temporal, but improved so that it was somewhat production ready. And there's a second polyfill called, I think full calendar Temporal polyfill. So that's an interesting story. I'm here in New York for the TC39 meeting this week. And so the author of this full calendar polyfill, Adam Shaw, he's contributed to the Temporal spec several times, actually found some really important bugs and opportunities for optimization. Because he wrote this polyfill for fun, he was interested in it. So I've talked to him on a few of the Temporal meetings and stuff, but last week he emailed me and said, 'Oh, I'm actually based near New York. Would it be possible for me to attend the TC39 plenary?' So we made that happen and that was pretty cool. It was great to meet him in person.
Eric Meyer: Yeah.
Philip Chimento: And we talked about, I asked him like, 'What made you interested in this?' It was kind of a side project for him. He actually has his own company that sells a daytime picker widget for the web. He's got an open source version and a premium version, and so he was kind of naturally interested in this. And then there's a third polyfill that was just released recently that's kind of more minimalistic. Doesn't bring all of the time zones that browsers bring, but the upside of that is it's got a smaller download. So yeah, there's a lot of choice if you want a polyfill.
Nicolò Ribaudo: It is very cool how Temporal has not been developed just by Igalia or by one company, but there is a whole group, both people from like different companies, but also just random individuals that just were very excited about time that got together and from this larger group that's been driving the proposal for the last many years.
Eric Meyer: So you say a lot of people interested in time. So we should probably talk just for a second about Temporal, just a quick summary of what Temporal makes possible.
Philip Chimento: So there's a bunch of different data types in Temporal. Like previously in JavaScript, we just had the date object that wasn't actually a date. It was a timestamp. So people would use that for timestamps, obviously. They would use it for UTC absolute times, they would use it for the times in their own time zones, for local times. And they would also use it to represent a particular date on the calendar without a time, just by like zeroing out the hour, minute and second and whatever. And that led to some unbelievable bugs. All these things that people used the old date object for, we have separate objects for those in Temporal. So there's Temporal.plaindate if you want a date on the calendar. There's Temporal.instant if you want a timestamp for your logs. There's Temporal.zoneddatetime. If you want a timestamp with a time zone for local time in a particular place on earth. And then there's a couple more things. There's plain time if you want a time on the clock without an associated date. There's plain date time if you want both a date and a time, but not a timestamp. I guess the jargon that we use for that is wall time because it's what you'd see on a calendar on your wall and the clock next to it on your wall. Then we have a couple of weirder types, one for a year and a month with no associated day. So it's like saying the March 2026 TC39 meeting. And then we have one for a month and a day without a year. So you could use that for your birthday and then you can convert that to a date for every year in which you want to calculate something about your birthday, for example.
Eric Meyer: And then it also has a whole bunch of like methods to be able to relate one thing to another. You can't necessarily calculate the interval between a timestamp and a month day, but you can calculate the interval between one timestamp and another. And also one wall time in another taking time zones into account. And Temporal also has built in like daylight saving shifts, which we just are going through right now. We're in that period where North America and Europe are, one's on summertime and one's not. And everybody's meetings go completely wonky. People are showing up an hour earlier, an hour late, but Temporal would resolve that for the most part if you use it, correct?
Philip Chimento: Yeah. I mean, your calendar software has got to use it. But yeah, like one of the things we've kind of recommended in the documentation for Temporal is that if you don't know what type you want to use, use the zone date time because that will at least prevent those kinds of bugs.
Eric Meyer: Yeah, it carries the most information, I guess. I've actually used it a little bit myself to make people feel old. I just wrote a little widget that I can give it today's date and some date in history, and it will tell me the exact midpoint between the two, taking into account a gazillion things. So like just at the end of February, February 26th was two of them. One of them is that Windows 1.0 was released closer to the end of fighting in World War II than it was to the present day.
Philip Chimento: Wow.
Eric Meyer: Yeah. It's up there with those. Cleopatra lived closer to us in time than she did to the construction of the pyramids, which always blows people's minds.
Philip Chimento: Wow.
Eric Meyer: History. For that matter, the Tyrannosaurus Rex lived closer to us in time than it did to the Stegosaurus. So whenever you see like Stegosaurus fighting T-Rex, either cloning was involved, thank you, Richard Hammond, or somebody doesn't know their Triassic, Cretaceous, et cetera, history.
Brian Kardell: So speaking of history, I think this is kind of a historic moment. I think when you look at some of the things that we've talked about here, things that Igalia has also worked on in a bunch of these cases, like CSS Grid, that is a sort of pivotal technology, right? It was a really hard thing. It wasn't getting anywhere. I got involved and eventually we got Grid. :has() the pseudo class, same thing. It was blocked for years and years and years, I mean like 20 years. But dates in JavaScript have been posed pretty much since the beginning. And one of the authors of Moment.js was part of TC39 and joined and proposed to replace the date object, to update the date object in 2017. So that's nine years, right? And I bring this up and I know this fact because we did an episode with Philip and Philipp Dunkel from Bloomberg and Maggie Johnson-Pint in 2021 when it was just recently had gone to stage three. So this is a really hard thing and a lot of people worked on this. And I have so many questions because like, what happened between 2021 and now? How much has changed? I think a lot of people out there are very curious about like, why do standards take so long? I mean, it's like 10 years. There are probably people who are listening to this who are like, 'I was in middle school or grade school when that was introduced when we knew that it was a problem. How have we not solved it by now?'
Nicolò Ribaudo: This is something that happens from many proposals, but when working within large features within TC39, it always takes a lot of time. Nine years can feel like a long time. There have been proposals that have been discussed for like 20 years at this point, like Decimal, which is another one we're working on. What happens is just that we want to make sure we have the best design possible there and different people in the committee have different opinions on what the best design possibility is. There is some subjectivity to it. And so we actually need to get all together and not really fight about our own opinion, but figure out what's actually good about one's opinion and somebody else's opinion and get them together. Opinions start mattering less once you reach stage three. So let's say the last four years for Temporal, because at that point it means we already kind of agreed about all the opinions of how the things should work. And then what starts is the engineering effort to actually make it happen, properly test it, and make sure that everything is right. And Temporal is maybe the largest proposal that we ever worked on TC39, which means not only there is a lot to standardize, but there is a whole lot to implement. And for browsers, this has been particularly a challenge. Philip has some stats, I think Temporal added maybe, I don't know,40% text to the JavaScript standard, which means it's just increasing below the browser API surface. And so you have to figure out how to implement this, and it's so large that also you're going to find bugs. I was not working on Temporal, but by just attending TC39 meetings every two months, every four months, I was hearing about bugs that were found in Temporal thanks to people implementing them or thanks to people writing tests for that. And then all of these things had to be brought back at TC39 meetings every time because as a group, we then always need to agree on what the solution is and that's just why it takes time. And I'm sure that Philip has a lot more details on like what were some of the challenging parts of proposal that actually were done like more on background or more difficult for browsers and so on.
Brian Kardell: We want to hear who was the jerk that held it up.
Philip Chimento: I'm not going to throw anybody under the bus like that. Probably in hindsight, like I've been working on this proposal for six years, so it was my first project when I joined Igalia and also my first thing that I worked on in this JavaScript standardization process. I think if somebody came to me now with a Temporal size proposal and said, let's do this in TC39, I'd say let's split it into smaller proposals. And still kind of think of it as a whole, like design sort of a roadmap for Temporal and make sure all the types work together, but also try to complete parts of it first and get those in so that people can start using them. I mean, that's actually, in a way, it's more work because you've got to think of what's least risky to add that you might have to take back later or that might constrain the design space. I think in hindsight, probably that would have been better than waiting nine years for the whole thing. But I wasn't there in the beginning and when it started, it was only a short time after ES6, which was a huge effort, much larger than Temporal. But yeah, that was before the current process of making things in proposals started. It was like, 'Oh, let's work on the whole edition of the language at once.' So it may not have seemed as large at the time that it was started that it does now. Now when we have other proposals going through TC39, that's like one method on array or something like that.
Brian Kardell: Can I interrupt with a quick question? So one thing that we didn't note is like, it's not just huge, it's top level object, right? There are very few top level objects in JavaScript. And maybe something to think about and compare and contrast is also there's a whole another 402 for intel, right? There's a whole nother TC, right?
Eric Meyer: Intel being internationalization or?
Brian Kardell: Yes. Another top level object that was added. It has like its own TC. But it's also like similarly big and top level and in some ways highly related because it deals with times and time formatting and date formatting and all that kind of stuff. And so I wonder if that also influenced the idea like we got to tackle it all in one kind of thing. And do you think that there's anything to that? And was it ever discussed about like maybe putting it in its own TC?
Philip Chimento: Yeah, we actually discussed that yesterday in the meeting. So TC39 is still decision making authority about intel, but it's delegated to a subcommittee. I mean, in a way, we've been doing that the whole time, just not officially, right? The people responsible for Temporal have been kind of a group varying in size from say three to six to nine, depending on who has time at that moment. But yeah, the standardization jargon is proposal champions. So we've been having these Temporal champions meetings for as long as I've been involved. So in a way, this is TC39 delegating the job of getting that done to a small group of people. Whether that's official with a subcommittee or not, I think it's a nice approach. There are upsides and downsides. I think definitely sometimes we brought items to TC39 just too kind of in the weeds for most committee members to care about. But then also, it's good to have some knowledge. Like you use the example of internationalization, it's good that there's at least some knowledge of internationalization in the wider committee and it's not just confined to this subcommittee. So there's different approaches and I think developing things in a small group works well and then sort of ratifying it in a large group.
Eric Meyer: And in Igalia chats first, we have a special guest joining us midway. Jason, can you please introduce yourself and let people know who you are and what you do and why we brought you on?
Jason Williams: Yeah, I'm Jason Williams. I'm a senior software engineer at Bloomberg. I'm mainly based in London, I'm in the application frameworks team. So I guess we're like an infrastructure team within Bloomberg, providing APIs and frameworks to the rest of the company. And yeah, we do a lot with JavaScript tooling. We use JavaScript a lot in Bloomberg, both on the server side. We actually have like SpiderMonkey running on the server side, but we also use it on the front end as well. So our terminal application is using Chromium and we use V8 for rendering on our front end. So we do a lot of stuff on the presentation layer too. Yeah, I guess I joined Bloomberg in 2019 and I was already doing some stuff with TC39 before that when I was at the BBC in the UK. And they tasked me with taking a look at Temporal and it was very new then. I think it had only been around maybe about two years and they said, 'Hey, do you want to take a look at this, help us out?' Temporal is important to Bloomberg as well. We do a lot of stuff with dates and times. As you can imagine, we have users all over the world and even things like stock exchanges and trade times and passing that data back and forth all over the place. So we have had our fair share of date, having to deal with date, having to patch it, having to add time zones. So I think Temple was very interesting to us and I was really happy to jump on it and get started on that. I was going to say it's the longest proposal I've ever worked on, but I think that might be true for anyone who's worked on Temporal. Yeah. And we have the same problems everybody else has, which is, are we displaying this time in UTC or are we displaying it in the local time or sometimes those things are the wrong way around. And so this helps everybody.
Eric Meyer: So you are a co-sponsor of Temporal, is that correct?
Jason Williams: Yeah, I think you can put it that way. We partnered with Igalia back in 2018. Essentially what happened is, as you probably know, there were one or two people working on it already in the shape of Maggie, Maggie Johnson-Pint and Matt Johnson, but we knew that it really needed to have some people working on it full-time. It definitely needed a lot of resources thrown at it because it was such a huge proposal. It's not something that could just be tackled here and there ad hoc every couple of weeks. And yeah, I think in 2018, we reached out to Igalia and we managed to have Philip join us and Ujjwal Sharma. But we also as well carried on. So Andrew Paprocki, who works at Bloomberg, Philipp Dunkel and myself, we also continue to try and be involved. But yeah, around 2018, that's when we sort of partnered up and tried to tackle this between us. So yeah, I guess you could say like a co-sponsor.
Nicolò Ribaudo: It is great that Bloomberg does this work with Igalia, because many people know Igalia for doing all of these great things on the web such as Temporal, but many of the things don't just come out of Igalia by themselves. It's because there are companies that work with us and fund us and make it possible for us to do all of this great work.
Jason Williams: Yeah, absolutely.
Eric Meyer: And I'm curious, because I actually don't know this, how many people between Igalia and Bloomberg, just those two companies have worked on this roughly?
Philip Chimento: From Igalia, there's a lot of people who have done, let's say, a stint of a few months on Temporal. During the whole five years that the proposal was stage three, there's been a lot of tests to be written. So that's something that people could easily kind of jump into in between other projects. So I don't know, it's probably about 10 people on the Igalia side, including yourself, Eric, because I should note that you wrote the first iteration of the documentation that's now on MDN for Temporal.
Eric Meyer: Right. That's true. That was my welcome to Igalia project basically when I was first hired. So back in 2021, basically I just went through the spec and wrote MDN. What's on now, actually Chen Xida did a pretty big overhaul. So I think he at least deserves co-credit, if not leading credit on what's actually on MDN, but he did basically take what I had written and update it, because the spec, I guess, did change in those five years. Stuff was removed, if I remember correctly, which is always interesting. I think people tend to think of standards as a process of adding things and don't really think about the standards process as sometimes a process of removing things. What's an example of something that got removed and why were things removed at all? I mean, stage three out of four sounds like we should be past the time where you're removing things and yet.
Philip Chimento: Yeah. So part of the standardization process is you ship something out to the web and ideally you want to never change it, or at least not in a backwards incompatible way, because you don't want websites to break. Besides the fact that people don't like it when their website breaks and they have to update it for some reasons out of their control. There's also kind of a philosophical reason, like the web is, it's the archive of a lot of the culture in many places in the world that we've had for the last 20 years and you don't want that to kind of rot due to incompatibility. So keeping things working and not breaking the web is a responsibility that TC39 takes very seriously. So we want to make sure that whatever we put out there is like enough to solve the problems that motivated Temporal, but also not more. So yeah, getting more concrete. A couple of years ago, some of the browsers were getting close to having a complete implementation that would have been ready to ship to the web generally. And there was kind of a concern in Chrome that Temporal was going to increase the binary size on Android too much all at once. Obviously as features get added to the web platform, the binary size is going to increase, but if it increases too much all at once, especially on resource constrained devices like wearables and stuff, too much all at once means that there's less room for other things to happen that also need to happen elsewhere in the web platform. And so we were asked to try and make the proposal smaller in order to kind of avoid this huge jump in the binary size. So we took a hard look at everything in the proposal and thought, okay, is this really necessary? What would be possible to get rid of without compromising the developer experience too much? And so there were some sort of methods that were just kind of for convenience and those were not too difficult to get rid of. But one thing that we'd had in the proposal for a long time since going to stage three was actually a facility for adding in your own time zones or your own calendars. And the idea was that people would be able to support time zone changes as soon as they happened rather than waiting for the browser to update their time zone database or to support calendars that are used somewhere in the world that aren't standardized in the Unicode data set yet. But when we were looking for things to remove from the proposal, we kind of took a look at this and said, 'All right, maybe this is one of the things that has a danger of not being quite as future-proof as the rest.' Actually, one of the motivations for having custom time zones in the first place was this iCal file format that various calendar software uses to communicate calendar events and they have support for custom time zone rules. So that was kind of one of the motivations that we had for that. And then we realized that in the meantime, since we designed the custom time zone stuff, they had actually decided to stop supporting that.
Eric Meyer: Oh, okay.
Philip Chimento: And there had been sort of other attempts to define a custom calendar format using just a adjacent data file, which also hadn't existed at the time we'd designed that feature. So that was kind of like, okay, well, there's some changes happening here that might allow us to bring the feature back better in the future. And if we do this now, we might be locking ourselves into something old, so let's just not do it. And it was actually a big part of the proposal to remove, so we were able to make the browsers happy by reducing the binary size. But also, if there's something where you might lock yourself into a certain design space that might not be ideal in the future, that's where you'd want to remove a feature from in the standardization process.
Jason Williams: I just wanted to add to that, that the complexity of custom time zones and custom calendars was huge. The number of tests we had around this time when we had both of those in was around 9,000 tests in Test 262, that was huge. When we removed support for custom time zones and custom calendars, that dropped to around, I think it was just over 4,000. So over half of the number of tests for Temporal were for, or at least supporting custom time zones and calendars. And Philip does mention Chrome, but actually other implementations were struggling with the complexity that they were bringing as well. So in Boa, the Rust JavaScript engine that had support for this at the time, there was a lot of complexity there. I think there was some polyfills as well that also had a huge amount of code to deal with custom time zones and calendars. So yeah, as Philip mentioned, we got together and we struggled to find enough real world use cases, I would say. We had hypothetical use cases, as Philip mentioned, maybe there's some organizations that might have a DST coming up and maybe the TV database is not going to update in time, so they want to take matters into their own hands and do that themselves, but we just didn't feel it was strong enough to keep around. And we really wanted to try and simplify the surface area of Temporal at the time. So yeah, sadly those two became candidates for something that we needed to remove.
Nicolò Ribaudo: It is very common in TC39 to slice off a part of proposal saying, 'Oh, we have this idea, but we'll do it later.' I wonder whether this is something that you think will come later for Temporal or do we have already other ideas of what the next years of evolution for Temporal will be like?
Jason Williams: So I can't speak about calendars, I'll let Philip answer that one, but I can say a little bit about time zones. We felt that even if people did want to patch time zones and add their own, we felt that the JavaScript level probably wouldn't have been the best level for this anyway. This may be something that you could do at the TZ database level. So of course the runtimes and the browsers are passing that data in. These days, Chrome is passing that data into V8. Node.js, for instance, is passing that into V8 also. So if people did want to add a custom time zone, maybe this is something that they could do as a patch. And then from that point onwards, the entire runtime right from the beginning has that, and there doesn't need to be any sort of special code or any classes or any sort of monkey patching to be done. Those custom time zones would just be there. So as a champions group, we felt that maybe this problem could be tackled at a lower level or somewhere different.
Brian Kardell: One question that I had actually is there's a bunch of things that go wrong when you try to use JavaScript dates. You try to add days or you try to add months to a date and it winds up in the wrong month. They're all kind of weird stuff. But one of the things that is really particularly difficult is trading dates and times and things when you have to put them into some data format like JSON or something and trade them. And I'm just wondering, how does Temporal deal with that? I think in some cases, the thing that they serialize doesn't even, like the two string is not even a date. It's like some other thing?
Nicolò Ribaudo: There is actually a completely new serialization format that was standardized for Temporal in ETF. Well, it was not completely new. It was based on previous formats, but we had to expand it to cover everything that was needed. I think it was one of our colleagues from Igalia that worked on that standardization process in a completely separate body from TC39. If anybody wants to look it up, it's RFC 9557. And that defines how to serialize data and times with all of this extra information Temporal provides. And that was also just by itself a huge effort. I think it was standardized maybe one year ago or two years ago at this point. And it's not only for JavaScript, the goal with that serialization is to be able to interoperate with other systems. And so there are already other systems that are looking to adopt in this same serialization format originally developed by Temporal.
Eric Meyer: Yeah. I want to bring it back just a little bit because this fascinates me as a front end guy. Jason, you were talking about how you're running SpiderMonkey on the server, but also it was mentioned that Temporal has support in Node.js and other things that are typically run on the server. So Temporal doesn't have to be completely client side. You could do all of the time calculations up on the server and then just send to everybody who needs it whatever they need. Was that always a design goal?
Jason Williams: Yeah. So yeah, like you said, it doesn't have to be a client side or presentation layer, API. It can be used server side. There are already people using Temporal server side via the polyfill. And I think it's just briefly been mentioned, but yeah, serialization is obviously the main way of doing that. And the design of that has been there from the beginning. We knew very early on that people would want to serialize these types and then send them around. It was a very easy decision to choose ISO 8601 for that. That's already the standard for serializing dates. That was a very easy decision. We don't guess or try to pause other types. It needs to be ISO 8601. I had a question yesterday when this went to stage four, which is, why can't this automatically deserialize back to the object I want? So why doesn't like JSON Parser just automatically give me back the object? We wanted this to be explicit and the onus should be on the developer to bring the date strings back to the type that they want. So for instance, if you're on the backend sending a date or a date time or a year month or month day to the client side and you're serializing that down to a string, then on the client side, you know already what type that is because you're the person who sent it on the other side so you know to revive that back to the correct type. And at least then there's no nasty surprises. For instance, if we had some sort of way of doing this automatically, you could end up having the wrong type and then now you have undefined behavior. At least now the developer is the person who's in charge of converting those serialized strings back into the right type. And I think that's a good decision, that was a very intentional decision that we had. And yeah, that should also help reduce the amount of bugs that can happen in a code base.
Eric Meyer: I like that that's a possibility where you might say, okay, we want to support showing the correct time in any browser, but we know that there are browsers that don't support this. So we'll do all of the code server side. And then all we need to know from the client side is like, where are you or what time zone are you? And then we can just send you, in this case, a serialized bit of data and then on the client side you reconstitute it into whatever you need. That makes a ton of sense. And it's a server side polyfill in a way?
Jason Williams: Yeah, absolutely.
Eric Meyer: Count the various pick a time services, right? Try to find a time for a meeting. Doodle is the one that comes to mind for me, but there are many. They could do all that, and they probably are doing all that on the server side, but they're using like Moment.js Or something like that. But now they could just do it natively in Node or whatever server side thing. And Moment.js, I bring that up because that has like a bearing on Temporal?
Jason Williams: That is correct, yeah. Maggie Johnson-Pint, who was a maintainer of Moment.js back in around 2015, 2016, she was working on the library back then and obviously trying to make it as good as possible for users. The criticism, I guess, that came up most of the time was size. Moment would come with locale information because it had support for formatting, and it would come with timezone information as well so that you had basically the entire TZ database was in there. And people couldn't really tree shake that out because they probably didn't know what time zones they wanted to deal with ahead of time or what locals they were going to deal with. So you often ended up with Moment.js being shipped to clients who are going to a particular website and it could be 280K, almost 300K, which is huge. The average website wasn't even that big around 2016, 2017. So the library was big. I think what made matters even worse is, of course you had CDMs that sped things up, but you then had sharding. So different websites, different origins were also not using the same cached libraries anymore. So you probably had a copy of Moment about 10 times in your browser cache. It was actually Maggie who realized that there's only so far you can go in user land. And also it doesn't make sense because the browser has this information anyway. So locale information, time zone information, that is all there. That is all in the browser. So maybe we should just expose that via an API rather than have a user land libraries that people use. So she went to the committee and the very first proposal, actually even the first proposal was called Temporal. She called it the Temporal proposal. And in 2017, yeah, that was when the conversation first started. And it turns out everyone in the committee was very supportive of the idea of finally having a new API to solve this. And her proposal went to stage one back in 2017. So yes.
Eric Meyer: Okay. Well, yeah, we're coming to the end of our time, but I just want to say thank you to everyone who joined. Jason, I'm going to start with you, where could people find you online and see what you're doing?
Jason Williams: Yeah. So you can find me on BlueSky. I am Jason Williams or Jason_Williams. Same on X as well. I am on BlueSky a bit more these days. I am also around on Matrix as well, JasW. I maintain the Boa project, so that's a JavaScript engine in Rust. So even if you went to the Matrix channel there, you can definitely catch me there as well. So all over the place. I think if you maybe just Google Jason Williams JavaScript or something, I'm sure I'll be at one of the top links anyway.
Eric Meyer: Oh, nice. Okay. Philip, how about you?
Philip Chimento: You can find me on a lot of places as Ptomato, P-T-O-M-A-T-O. And on BlueSky, it's the ptomato.name.
Eric Meyer: Okay. And how about you, Nic?
Nicolò Ribaudo: My website is nicr.dev. That's also my BlueSky handle and you can find all the contacts you want there.
Eric Meyer: Awesome. Well, thank you all so much for joining us and talking about Temporal. Really, I mean, stage four, once again, woo-hoo. Party emoji. Looking forward to working more with it in the future.
Brian Kardell: Yeah. Thanks for joining us and thanks for all the work.
Eric Meyer: Yeah.
Brian Kardell: And thanks to Bloomberg for all the funding.
Brian Kardell
Eric Meyer
Nicolò Ribaudo
Philip Chimento
Jason Williams