The Clock Thickens: Temporal Advances to Stage 4

All right, hi, I'm Brian Cardell and I'm a Developer Advocate at Egalia.

And I'm Eric Meyer, also a Developer Advocate at Egalia,

and today we're going to be talking about time

with two of our fellow Egalians, Nick and Philip.

So Nick, please introduce yourself first.

Hi, I'm Nick Nicolo.

I work on a bunch of dessert and stuff at Egalia.

Most of the modules that I'm pretty much involved in,

all of the proposals that are doing.

Philip.

Yeah, I'm Philip Kemento.

I'm also an engineer at Egalia and I work also mostly on JavaScript standards

and JavaScript engines.

And we have news.

We do indeed.

Yesterday at the time of recording this,

the temporal proposal went to stage four in TC39.

Nice.

Woohoo!

But for those who might not be familiar with TC39,

what does it mean to head stage four?

So there's a whole stage process in TC39 for proposals

before they actually become part of the JavaScript language.

And goals 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 is going to be part of it.

And part of the requirements for that is that it's available in two major implementations.

It means stage four does actually mean that people can use it yet.

Two implementations means that we have two browsers supported,

but like if you want to wait for it to be probably at least baseline,

so that it works across less than four 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 browsers,

specific servers at runtime.

Okay, so you say at least two browsers.

Stage four means we have two browsers, which two browsers are those?

They're Firefox and Chrome.

Okay, and do we know what the status is with WebKit,

like should that be coming?

That's something that we have actually been working on at DeGalia.

Our coworker Tim did a whole bunch of it last year.

And some of it is in Safari Technology Preview now.

Yeah.

And 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 internet where you actually control that kind of thing.

Those would be great times to start using it.

There is a polyfill as well.

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 Eglia and a couple of others

who 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.

Yeah.

And we talked about, I asked him 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.

It doesn't bring all of the time zones that browsers bring.

But you know, in the upside of that is it's got a smaller download.

So yeah, there's a lot of choice if you want to probably fill.

It is very cool how Temporas not been developed just by Egalia or by one company.

But there is a whole group.

Both of people from like different companies,

but also just running.

Visuals are just very excited about time that I got together.

And from this larger group that's trying to proposal for the last many years.

So you say a lot of people interested in time.

So we should probably talk about just for a second about Temporal.

Just a quick summary of what Temporal makes possible.

So there's a bunch of different data types in Temporal.

Like previously in JavaScript, we just had the date objects that wasn't actually a date.

It was a timestamp.

So people would use that for timestamps, obviously.

They would use it for, you know, for UTC absolute times.

They would use it for, you know, 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, the minute and seconds and whatever.

And that led to some unbelievable bugs.

So we have, we have all these, like all these things that people used the old date object for.

We have separate objects for those in, in Temporal.

So there's, there's Temporal dot plane date.

If you want to date on the calendar, you know, there's Temporal dot instant.

If you want a timestamp for, for your logs, there's Temporal dot zone date time.

There's a timestamp with a time zone for, you know, local time in a particular place on Earth.

And then there's, there's a couple more things.

There's, there's plane time if you want a time on the clock without an associated date.

There's plane date time if you want both a date and a time, but not a timestamp.

You know, I guess the jargon that we use for that is wall time because it's, you know,

what you'd see on a calendar on your wall and the clock next to it on, on your wall.

We have a couple of weirder types, you know, one for a year and a month with no associated day.

So it's like saying, you know, the March 2026 TC 39 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 know, you can convert that to a date for every year in which you want to calculate something about your birthday, for example.

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 time stamp and a month day, but you can calculate the interval between one time stamp and another.

And also one wall time and 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 ones on summertime and one's not.

And everybody's meetings go completely wonky.

Like people are showing up an hour earlier and hourly, but temporal would resolve that for the most part if you use it, correct?

Yeah, I mean, you're your calendar software has got to use it.

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.

Yeah, I carry 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 like 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, we actually had a February 26 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.

So yeah, you know, it's up there with those, you know, Cleopatra lived closer to us in time than she did to the construction of the pyramids, which always blows people's minds.

Wow, history.

Yeah, and 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 a cloning was involved, thank you Richard Hammond, or somebody doesn't know their Triassic, Cretaceous, et cetera, history.

So speaking of history, I think this is like kind of a historic moment.

I think when you look at some of the things that we've talked about here, things that Agalia has also worked on in a bunch of these cases, like CSS Grid, that is a sort of pivotal technology, right?

Like it was a really hard thing.

It wasn't getting anywhere.

It got involved and eventually we got Grid has the pseudo class same thing.

It was like blocked for years and years and years, I mean like 20 years.

But dates in JavaScript have been host like pretty much since the beginning.

And the author of 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 right 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 Philip Dunkel from Bloomberg and Maggie Johnson pipe in 2021 when it was just recently had gone to stage three.

So this is a really hard thing and like a lot of people worked on this and I like I have so many questions because like what happened between 2021 and now like how much has changed?

You know, 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, you know, 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?

This is some happens for 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 I've been discussed for like 20 years at this point, like decimal, which is another one for 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 possibilities.

There is some subjectivity to it.

And so we actually need to get all together and like not really fight about our own opinion, but like figure out what's actually good about once opinion and some of this opinion gets them together.

Opinions start wondering less once you reach stage three.

So let's say last four years for temporal because at that point, it means we're ready kind of grid about all the opinions of how the thing should work.

And then what starts it the engineering effort to actually make it happen properly tested 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 a particularly challenge.

Philip has had some some stats. I think like temporal is that they may be, I don't know, 40 percent extra to the just get standard, which means like it's just increasing a lot 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.

So as I was not working on the temporal, but by just attending TC9 meetings every and every two months, every four months, I was hearing about bugs that are 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 this in the 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 that like challenge parts of proposal that actually were not like more bug prong or more difficult for browsers and so on.

We want to hear who is the jerk to hold it up.

I'm not going to throw anybody under the bus like that.

And probably in hindsight, like I've been working on this proposal for for six years.

So it was my first project when I joined igalia and I'm also my first thing that I that I worked on in sort of 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 let's split it into smaller proposals.

You know, still kind of think of it as a whole like design, you know, design temporal design sort of a roadmap for 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 that's actually in a way it's more work because you've got to think of, you know, what's least risky to add that you might have to take back later or that 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 you know, I wasn't there in the beginning and when it started, it was only a short time after yes, six, which was a huge effort much larger than temporal.

But yeah, that that was before the the current process of of of making things in proposals started. It was like, oh, let's work on the whole addition of the language at once.

So, you know, it may not have seemed as large at the time that it was started that it does now like now when we have other proposals going through TC 39 that's like one method on array or something like that.

Can I interrupt with a quick question? So one one thing that we didn't notice like this is a it's not just huge as top level object, right?

Like there are very few top level objects in JavaScript and maybe something to think about in compare and contrast is also there's a whole nother 402 for Intel, right?

There's a whole nother TC, right? Like until being internationalization or 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 like highly related, right? Because it feels with times and time formatting and day formatting and all that kind of stuff.

And so I wonder if that also influenced the idea like let's got 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?

Yeah, we actually discussed that yesterday in the meeting.

Yeah, so TC39 is still a decision making authority about Intel, but it's it's delegated to to a subcommittee and 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 you know, we've been having these temporal champions meetings for as long as I've been involved.

And so in a way, you know, this is TC39 delegating the job of getting that done to a small group of people, you know, whether that's official with a subcommittee or not, I think it's a nice approach.

There are there are upsides and downsides like I think definitely sometimes we brought items to TC39 that just too kind of in the weeds for most committee members to care about.

But then also it's you know, it's it's good to have some knowledge like you know, you use the example of of internationalization.

It's good that there's at least some knowledge of internationalization in in the wider committee and it is 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.

And in an agalia 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 to do and why we're brought you on.

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 spider monkey 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 that 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 TC 39 before that when I was at the BDC 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, you know, you want to take a look at this help us out.

Temporal is up is is importance 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 zone.

So I think Temporal is 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 proposed live ever worked on but I think that might be true for anyone who's worked on Temporal.

Yeah, and we have the same problem to everybody else has, which is, are we displaying this time in UTC or are we displaying it in local time or sometimes those things are the wrong way around.

And so this helps everybody.

So you are a co-sponsor of Temporal, is that correct?

Yeah, I think you can put it that way. We partnered with a Gallia back in 2018.

It was something that essentially what happened is as you probably know there were one or two people working on it already.

In the shape of Maggie and Maggie Johnson Pinson 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 a Gallia and we managed to have Philip join us and Ijoua Shouama.

But we also as well carried on. So Andrew Paproki who works at Bloomberg, Philip Donkel and myself.

We also continue to try and be involved.

But yeah, around 2018 that's when we sort of partnered up and try to tackle this between us.

So yeah, I guess you could say like a close concert.

It is great that Bloomberg does this work with the Gallia because like many people know Gallia for doing all of these great things on the web, such as temporal.

But many of the things don't just come out of the Gallia but themselves.

It's because there are companies that work with us and have found us and make it possible for us to do all of this great work.

Yeah, absolutely.

And I'm curious because I actually don't know this.

How many people between Gallian and Bloomberg just those two companies have worked on us roughly?

There's from from a Gallia.

There's a lot of people who have done.

Let's say a stint of a few months on on temporal.

You know, there's a lot of during the during the whole 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 Gallia side, including yourself, Eric, because I should note that you wrote the first iteration of the documentation that's now on MDN for temporal.

Right, that's true. That was my welcome to a Gallia 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 Zida 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 updated because the spec, I guess, did change in those five years, like 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 sandwich process as sometimes a process of removing things.

What's an example of something that got removed and why were things removed at all?

Your stage three out of four sounds like we should be past the time where you're removing things and yet.

Yeah, so like the part of the standardization process is like 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 like 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.

And so yeah, getting more concrete a couple of years ago, you know, some of the browsers were getting close to having a complete implementation that would have been ready to ship, you know, 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.

So like obviously as, you know, 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 on resource constrained devices like wearables and stuff that's, you know, that's.

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.

So we were asked to try and make the proposal smaller in order to kind of avoid this huge jump in the binary size.

Say 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 this, you know, people would be able to support time zone changes as soon as they happen rather than waiting for the browser to update their time zone database or to support, you know, calendars that are used, you know, somewhere in the world that aren't standardized in sort of the unicode data set yet.

But, you know, when we were looking for things to remove from the proposal, we kind of took a look at this and said, all right, you know, maybe this is one of the things that.

Has has a danger of not being quite as future proof as as the rest like actually one of the motivations for having custom time zones in the first place was this I call 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.

Oh, okay.

And there had been sort of other attempts to define a custom calendar format using just a Jason data file, which also hadn't existed at the time we designed that feature.

So that was kind of like, okay, well, there's some 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.

Reducing the binary size, but you know, it's also, you know, 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 in the standardization process.

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 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 test with import 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, in, in Bella, the rest jump jump jump engine that had support for this at the time.

There was a lot of complexity there. I think there was some polyfields 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 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 TZ database is not going to update in time today,

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 temple at the time.

So yeah, sadly those two became candidates for something that we needed to remove.

It is very common is there nine to slice off a part of our poll 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, what the next years of evolution for temporal will be like.

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, you know, of course, the runtimes and the browsers are passing that data in these days, Chrome is passing that data into V8.

No 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.

One question that I had actually is, you know, there's a bunch of things that go wrong when you try to use JavaScript dates.

You try to add like days or you try to add months to a date and it like winds up in the wrong like 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 when you have to put them into some data format like Jason or something and trade them.

And I'm just wondering like, how does temporal deal with that?

I think in some cases like the thing that they realized doesn't even like the two string is not even a date. It's like some other thing.

There is actually a completing utilization format that was standardized for temporal in a ETF. Well, it was not complete.

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 Gallaud which worked on that standardism process in like a completed separate body from the 39.

If anybody wants to look it up, it's RFC 9557.

And that defines how to utilize date and times with like all of this extra information to provide.

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, like the goal with that serialization is to be able to interrupt with other systems.

And so there are already other systems that are looking to adopt in this same serialization format originally developed by temporal.

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 Spider-Monkey on the server.

But also what was mentioned, the temporal has support like 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?

Yeah, I mean, 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 parse 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 do serialize back to the object I want?

So why doesn't like Jason Paz just automatically give me back the object?

We wanted this to be explicit and the owners 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 back end 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 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 that was a very intentional decision that we had.

And yet that should also help reduce the amount of bugs that can happen in a code base.

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 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 reconstituted into whatever you need.

Like that makes a ton of sense and it's it's a server side polyfill in a way.

Yeah, absolutely. Yeah.

You know, count the various pick a time services, right?

Like try to find a time for a meeting doodle is the one that comes to mind for me, but there are many.

You know, 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.

That is correct. Yeah. Maggie Johnson Pinty 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 precise.

You know, moment would come with local information because it had support for formatting.

And it would come with time zone information as well.

So that you had the 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 at the ahead of time or what local's that we're going to deal with.

So you often ended up with moment JS being shipped to clients who are down low who are going to a particular website and it could be

280 K almost 300 K which which is huge, you know, the average website wasn't even that big around 2016, 2017.

So the library was big. I think what made matters even worse is we had of course you had CDNs that sped things up.

But you then had sharding so different websites, different origins were also not using the same cash libraries anymore.

So you probably had a copy of moments 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 local information, time zone information, that is all there, that is all in the browser.

So maybe we should just expose that where 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 Tempor.

She called it the Tempor 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.

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.

What I'm going to start with you. Where can people find you online and see what you're doing?

Yeah, so you can find me on Blue Sky.

I am Jason Williams, Jason on the school Williams.

Same on X as well. I am on Blue Sky a bit more these days.

I am also around on matrix as well, Jase, Jase W.

I maintain the Boa projects and that's a JavaScript engine in Rust.

So even if you went to the matrix channel there and 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 one of the top links anyway.

Oh, nice. Okay. Philip, how about you?

You can find me on a lot of places as tomato, PTO and METO.

And on Blue Sky, it's tomato.name.

Okay. And how about you, Nick?

My website is nickr.dev. That's also my Blue Sky handle.

And you can find all contacts you want there.

Awesome. Well, thank you all so much for joining us and talking about temporal.

Really, I mean, stage four, once again, party emoji.

Looking forward to working more with it in the future.

Yeah, thanks for joining us and thanks for all the work.

Yeah.

And thanks to Bloomberg for all the funding.