• Brian Kardell
• Maggie Johnson-Pint
• Philip Chimento
• Philipp Dunkel ("Pip")

Transcription

• Brian Kardell: Okay. So I am Brian Kardell and the topic for today's chat is Temporal, which is a new standard way and ECMA Script to deal with time, which we'll talk about. Time and standards make their way into a lot of my talks and posts. I talk frequently about standardization and how the modern idea of standard bodies and everything is kind of young. Modern forces were born largely in industrialization, sort of force the issue and its surprising for me to how much this is rooted in time actually. So I think that we have a perfect group to talk about not only Temporal, but a lot of the reasoning, and the standard story and everything behind it. So, I'm here with some guests, I'm going to let them introduce their selves.

• Maggie Johnson-Pint: Hi, I'm Maggie Johnson-Pint. I brought the original Temporal proposal to update the data object and the JavaScript in 2017. On top of that, I'm a technically a maintainer of Moment.js, though everyone knows now, its pretty much a winding down project. For my regular job, I'm a Product Lead on the Azure SDK.

• Philip Chimento: Hey everyone, I'm Philip Chimento. I work at Igalia on the compiler's team where we do things like participating in standards processes like for example, Temporal. I joined working on Temporal about a little over a year ago, and I've been part of the group that's made the decisions that allotted it to get to stage three in TC39 and the standardization process.

• Philipp Dunkel ("Pip"): Hi, I'm Pip Dunkel. I work for Bloomberg in JavaScript Infrastructure. I got involved in Temporal two, three years back now by raising my hand at the wrong moment when it came to, 'Lets try this out in a Polyfill,' and I've been driving it forward ever since.

• Maggie Johnson-Pint: That's very true. That's exactly what happened, I remember.

• Brian Kardell: Does anybody want to give me a summary, or if you want maybe I can give a summary, of what is Temporal?

• Maggie Johnson-Pint: Temporal is a set of, actually multiple objects or types that represent the problem domain of date and time very well. It makes sure to bring in much better time zones support story for JavaScript. It allows us to more clearly express in our code what we're trying to do with date and time operations.

• Philipp Dunkel ("Pip"): Basically JavaScript and date as a thing was introduced sort of as an afterthought and just a copy of java.util.Date, right? And java.util.Date wasn't all that great to begin with. There are a whole bunch of issues with it. So for one thing, the concept of dates containing time is questionable because most people think of a date as just a 'day', right? You think of your birth date, not of as a time point but rather as a day, right? Then you think of time separately from that and then you can combine them and have date-times.So it's a much more complex field than just a class like date and that's not even looking at the complexities yet in terms of cultures because date in the US, yeah, java.util.Date is fine, but then add time zones to that. Then add cultures that actually don't use our Proleptic Gregorian calendar as a standard. Then look at the sea world that is basically just working in seconds since epoch of whatever that system thinks is epoch.So dates have never been a good thing in any computing. So I don't think there's a computing language out there right now that has good dates and time and handling all that that is actually consistent. Becoming more global through web apps and not just local, be it the US market, or be it the Western market, or whatever, has really forced web applications developers and web developers specifically to worry about, 'How do I represent dates? How do I represent time?' And that's when Moment came along to fill that niche. Temporal is really the logical conclusion of all the things we've learned.A perfect example of where I just really got angry yesterday was, I am an Austrian citizen and I live in the UK, and I've gotten a letter yesterday from the Austrian embassy, and it was using... Because it was written in English, month-date-year as the date format, but it was unrecognizable as such because it was July 8th. So is it July 8th or August 7th? Which one is it? And you don't know and can't even tell from the context, because the context would be, 'This is the UK, the embassy in the UK, sending a letter,' right? Why they would use a month-date-year format? Who knows? That kind of thing has never really been well represented in any computing across borders, and not even within borders really.So Temporal is sort of the attempt to take all the learning of all the things that came before, including Moment.js and the concept of web apps being transnational and transcultural, and the attempt to actually give dates and time not just short shrift like in the past, but make them actual first class well-supported things. Me personally, I think that after Temporal, JavaScript will be the go-to language for anything happen to do with dates and times.

• Brian Kardell: I was a user of java.util.Date at the time and it takes this really sort of naïve thinking, which is natural right? Its natural to think time is just like this counter that keeps going, like its this very linear thing, and what you're doing is referring to some point in it and we then have different degrees of granularity. Is it a day, is it a month, is it a year, like that's very simple, but then as you start to dig into it, it obviously gets much more complicated. When you try to do things, it's sort of terrible.So, even in Java, the original date library was pretty quickly deprecated and I remember there was a whole site about this, yourcalendarfallacyis.com. Maggie wrote an excellent piece at the start of this talking about some of the history, and Maggie was also on Moment, which it was much better than Date. Maggie, can you tell the story of any of that?

• Maggie Johnson-Pint: Sure. Certainly, there's some things that Moment improved greatly about date. You can add a Moment, like on a date object, you have to do set date plus day plus one to add a day or something, it was wild. So Moment picked some things like that in a really good way. It's date, if you use day it will turn out wrong, that's another problem with the object. I still screw it up. So Moment fixed some things like that. It certainly gives you some better convenience APIs, but there are a few things that we really couldn't fix in Moment.I think the fundamental concept that you were getting at, Brian, that people need to understand about date libraries and working with date, time, and programming. I always say that there's a difference between timeline math on the global timeline and calendar math. Those two are very conceptually different things. If you're working in units of, I generally say hours or less, and there's a caveat here around the seconds, but if you're working in units of hours or less and you're working with actual points in time that you can map to UTC. Like we all got on this call, we're all in different places, but we all pick the same point and time in UTC to get on this call, then we would figure out one hour later by moving along UTC, by moving along the global timeline, and that's one kind of math.But if we want to figure out on a given day and the calendar what a month from now is, that's actually an entirely different kind of math. The way you're going to do that is not by moving along the UTC timeline. You're going to do that by almost imagining your flipping through the pages of the calendar because obviously not all the months are the same length and stuff like that. So one of the best things about breaking apart into multiple types and multiple objects is that we can create a kind of distinct calendar math objects that are separate from our timeline math objects, which is a huge advantage that we didn't have with the original date objects.Some other really fundamental problems, time zones just weren't exposed. There was no exposure through the language, through the browser, through JavaScript of time zones data for anywhere other than where you currently are in UTC, which is huge. There's a huge amount of use cases you can't cover, and you see a million people complaining, 'Well, I had to go into all of these time zones from Moment time zones and now my bundle size is huge.' Well, yeah, it is.So we needed to solve that and then the other two really fundamental issues with date. Mutability, the object would mutate when you did operations on it like an add or something like that, and we carry that through into Moment and absolutely we could have fixed that in User Land, but at a certain point, with the other problems around time zones and needing the rig of the type system. It made more sense to pursue standardization than to pursue a Moment three, though we kind of did that too with Luxon, we kind of do both.Then the last thing is that I'm sure everyone knows that the date parse behavior, when you pass a string into date is wild. It does not do what anyone would expect. It makes some really odd compromises. It makes some really add compromises between ES5 and ES6, as you want to call it. There was a lot of stuff that was time for a do-over.

• Brian Kardell: What a lot of people don't see is the pains that people have with Moment and the pains that the maintainers have with Moment. I'm not sure how many people realized that there was this kind of Moment three thing that you're talking about. I'm not sure how many people realize that or that it was basically the same Moment people saying like, 'We got some things wrong.'

• Maggie Johnson-Pint: Sure, so that was Luxon.

• Brian Kardell: Yeah, and the question is why go invent a new thing to standardize Moment three or to standardize Moment, right? Like I haven't asked that really directly in the same way that we're asked like, 'Why didn't you just standardized j.query?' I don't know if you want to respond to that. I feel like you did a pretty good job explaining it but if you want to add anything, now would be a good time.

• Maggie Johnson-Pint: You already heard what I said about... Actually this domain is more complex than one type. You want to be able to represent timeline math separate from calendar math. Philip was talking earlier about you want to represent days separate from time, these are all different concepts, and as you introduce them into code, it creates a lot of clarity in the code for the future reader about what is it that you're really trying to achieve here and I think that's really valuable for people but also as far as we're not just standardize Moment, I guess a few other things that I'll throw in, trends regards languages.You see Java breaking out into the type system that were bringing in Moment with multiple types. Python and Ruby also use kind of split multiple types, it's not exactly the same .NET 6. My husband literally just introduced date and time to .NET 6, we're both nerds, but he did the code contribution for that and .NET 6 and that's coming out soon.So there's some generally co-system migration to these multi-types systems that a lot of people do kind of bring that conceptual model across platforms. But also, we saw with Moment the mistakes when you didn't have that. We saw the number of [inaudible 00:13:08] issues and stock overflow issues. We were just answering the same thing over and over again because the API doesn't really provide that clarity to the user, motivated us in this direction and at the same time, we shipped Luxon which I think many people use now and that was Isaac, he's the maintainer of Moment. If you look closely, it's in the Moment GitHub work and that was our answer in User Land for people who wanted something now and also for people who don't like this big broken up type system and like the single object as it trends closer to that in these coding patterns there.The last thing that I think is important why we didn't... I think why we went to standards, it's not why we didn't standardize Moments API exactly. Why we went to standards is it was just so big. People kept telling us it was big and they're like, 'You have to tree shape this,' and we're like you don't understand, we use that code. You can't tree shape a code you used. There are probably more things we could have done to reduce the bundle size but like in practice, none of them were easy.

• Brian Kardell: So, I wonder if how many people listening are doing the date math in their head and saying, 'Okay, that was 2017, now its 2021 and its finally made it to stage three only recently. Jeez, what take so long?, but that's pretty fast on the standard's timeline actually, that's not exceptionally long.

• Philipp Dunkel ("Pip"): Yeah, actually I think, in that context, it's actually very important to realize that the standards part of it, which started 2017, is only really the last chapter. So if you think about it, the whole thing developed from a community need for proper date and time handling, and that means the first attempt at this really is Moment with one and two and then the ideas of Luxon and at the same time going into the standards body, then taking some of the things Luxon does and all of the learnings that Moment has done, and all of the experience that people built up over years and years and years and then bring that as a proposal to the standards body, and then create a Polyfill for the people to play with and do first things with. Then, publish that and get that feedback.So if you think about it that way, you say the standard for standards work, this isn't really all that long, which is right. 2017 to now isn't all that long in standards work. But if you take the whole body of work from the Moment.js started, until now, I would consider that the incubation period for this proposal. So I always say that Temporal is really the grandson of Moment. If you look at it that way, then it's a huge, very lengthy standardization process where we've basically taken the beaten path and taken all the learnings we've had and applied them to what we finally put into the language and all the feedback that has been gathered through those multiple years. So I think that's probably the better way to think of it.

• Brian Kardell: I think there's a good question here that will get lost to history maybe, if we don't talk about it, which is, What is in stage three currently as of right now? How similar is it to the original proposal that you wrote on the train?

• Maggie Johnson-Pint: The basic idea that we were going to have this split-type system is certainly still there, I believe that we developed it that time some of the patterns for passing object property bags I believe are still there. But a lot of it is quite different, there was definitely this point in time where admittedly, I had taken a lot of plane rides to a lot of standards community meetings, and I was kind of done and Philipp was willing to do it and I was willing to let him. So I think at this point, he should kind of pick up the story from there.

• Philipp Dunkel ("Pip"): Okay I guess I'll pick up that story. Its actually surprisingly similar, what's changed is the volume. So from that initial proposal which basically did that split between working along a UTC timeline versus working in dates and times as date math and time math. We've also added representations for common things like, think of a birthday which consists of a month and a day because it repeats every year, or things like year-months which is like what is when if you want to refer to February 2000, the February 2000 meaning of something where you know the month and the year it's supposed to take place, but you don't have exact dates yet, like think of how would you schedule a future TC39 meeting. You know what year, you know what month, but you have no idea about the day yet. So, that was added.Then, what also came to it was not just time zones as a factor, but we realized that actually calendars are just as important. That there's a large part of the world out there that doesn't work with January through December, they work in completely different calendars and they only use, if at all, the Gregorian calendar for computing. So examples of that would be basically the entire Muslim world works off different versions of different Islamic calendars. That's what all dates and times and official statements are put as, that's what holidays are defined by. Then there's the Hebrew calendar which is relevant for all the Jewish holidays. Then there is the Japanese calendar which is in use in Japan itself, and they only really use the Gregorian calendar when they interact with the Western world or in computing because there isn't a good alternative, and so on.There's a Hindu calendar, there's a Chinese calendar, there are calendars all over the place that are actually in daily use for people and they only really use the Gregorian calendar because there is no computing alternative. So that's another big add to that but other than that, it's actually, I think, fairly similar to the Temporal as I got to know it in what was it? 2018, I think.

• Maggie Johnson-Pint: Still no mars.

• Philipp Dunkel ("Pip"): Still no mars.

• Maggie Johnson-Pint: That was my favorite question ever in a TC39 meeting like, 'Maggie, were supposed to con as Mars soon, will this object be able to support that?'

• Philipp Dunkel ("Pip"): But you can do Mars, that's a nice thing. We design it flexibly enough so that you can actually do Mars if you want it.

• Philip Chimento: I was going to say another thing that I think was added, maybe halfway through the process was Temporal.duration and all the facilities there for taking the length of time and say rounding it to the nearest week or getting the length of time and then getting the total in nanoseconds. Those were all things that are new in the year that I've been involved with this. Moment has some of those I think and other date and time libraries have some of those, but yeah, there's some really interesting things you can do with durations like rounded duration to the nearest months relative to the start date in a particular calendar.

• Brian Kardell: Yes, so there are several things that I think are really cool and interesting about Temporal. One is that it is kind of a significant ad of a rare sort to JavaScript, like it's a whole standard library for time effectively. Ads of that sort are very rare, like Intel is it's own whole committee. Then, ECMAScript, the standards' committee for TC39 is in charge of the core language, but internationalization has its whole own ECMA-402 and is a large ad. We have very few, sort of top level objects that are rich with their own APIs like math or Intl.

• Philipp Dunkel ("Pip"): Yeah and actually its one that intersect with Temporal enormously because as I said, different cultures interacting with dates and time, and calendars, and time zones differently, all of that multiplied really by the number of cultures that internationalization supports. So we've actually been working very closely with ECMA-402 and there's a lot of overlap with ECMA-402 to get Temporal done.

• Maggie Johnson-Pint: I think its worth noting that everyone wanted this one like, you go to TC39 meeting and on any given proposal, people are going to feel many different ways. There's a lot of people in the room, and I don't remember anyone ever being like, 'We shouldn't fix date functionality.'

• Philipp Dunkel ("Pip"): Right, right.

• Maggie Johnson-Pint: Its one of the most universally liked proposals. Not that everybody agreed on the approach but its one of the most universally liked concepts and I think that's what it gets such a big proposal through the end of the day.

• Philipp Dunkel ("Pip"): Absolutely. I mean even since we've reached stage three, I think I've had like 10 different groups of people come at me, both from inside Bloomberg, as well as from outside, sort of asking, 'So when is this actually going to hit browsers? I really want to use this. We're waiting for just this.' So the enthusiasm, both in the community as well in the company's, as well as in the committee is definitely there for it.

• Philip Chimento: Temporal is quite large as JavaScript proposals go. This means that if you're reading a proposal for something smaller like the [inaudible 00:23:19] operator, its quite easy to look at the review for that proposal and understand what it does. Temporal is huge and so it allowed us to take the opportunity to not just write the specification text in the proposal, but also give people a Polyfill to try out and write a guide documentation,

• Brian Kardell: This is actually, when I said there's a couple of things that I really liked that I thought was really interesting. The other one was this. One of the biggest ways that standardization has evolved over the years is increasing the touchpoints of how can we involve and who we involve in the process. While I would argue that it still in many ways very imperfect and we're still figuring it out, I really liked when we are able to create some kind of Polyfill or something that really lowers the barrier for developers to get a sense, like a real sense, without volumes or explainers, and waiting through GitHub issues, and reading minutes and everything.A lot of things about standards operate on a timeframe that developers cannot possibly be involved in, but if you give them a thing and say, this is pretty much the thing, you can ask questions on it and maybe even try to do a useful thing with it that might be beneficial that you could choose another solution but you can try this one and give us some feedback. So I really liked that we did that and can we talk a little bit about, have we got feedback? And if and how that shaped anything?

• Philip Chimento: Yeah, sure. So this is something that we worked on starting last summer after most of the questions about what do we want the API to do this or that or have been worked out. At one point, we just drew a line under it and said this is ready to publicize more widely to get feedback. So what we did was ran a couple of blog posts and spread them around, and I wrote a survey, sort of developer's survey. What we did was publicized it on Twitter and in other channels asking people to try out writing some simple code with Polyfill, and then do the survey and let us know what they thought.So we actually got quite a lot of responses on that survey. Its like Maggie said, people have been awaiting this. They are eager to try it. They want to see it. So there were actually a lot of people who obligingly tried out the Polyfill and filled out the survey. I think the problem with it, the most important is the feedback that we got from the survey that showed up the most consistently was that people said there's a lot of keystrokes to do things in general.The APIs very robust because at that time, there was a lot of, like if you wanted to add a month, you had to add the Temporal.duration from months one. So obviously everything that everybody says in the survey is not necessarily something that you can implement like just as they want, you sort of have to take the feedback, interpret it, and synthesize it into something that you can act on. When something shows up so consistently where people said, 'Well, I really wish it was shorter,' and so many people said that. That was a clear signal to go back and examine what could we do to make operations shorter.That's kind of what we did, we lighted a lot of those from operations that were necessary that time, made them unnecessary. Like people had a lot of suggestions for what to make shorter and we didn't necessarily take all of those because sometimes there's a good reason to have an explicit step somewhere.But basically we took a look at the whole proposal and tried to identify any areas where it could be made more concise, the code that you would write with it. I think that really led to a lot of improvements throughout the API, and just through this feedback that came for too long.

• Philipp Dunkel ("Pip"): Yeah, I mean the example that you mentioned is that for a lot of input, you can actually just input your value as an ISO 8601 string and that came straight out of the 'Oh, this is so lengthy and you need so many prompts.' So most of the functions now accept a string variant that's in, as long it's an ISO 8601 format, is acceptable as input. That's an example of what came directly out of that survey saying make things shorter.Yeah, and I think that one of the people that actually gave the highest quality feedback and the most thoughtful input based on I think it was that survey or was it the Polyfill before that, then actually joined the core group of people working on this is Justin Grant. We invited him to collaborate because his feedback and his input was actually really thoughtful and really valuable. So we said that, 'I know you don't work for one of the member companies and aren't the delegate but come on, your input is actually helpful, so let's go.' So I think from that perspective, that survey opened a lot of doors.

• Brian Kardell: Yeah, I think that's there many different kinds of things you get out of it, so one is like finding new people who can participate in a really high quality way directly in making it better. Another is like are there general things across the board that we can look at and maybe improve and here is a good example of where maybe some of that happened. But another one is finding out the things that people are going to have reaction to, but they are the way that they are and its like an important thing to prepare for how you explain it.So, sometimes a thing has to be a way for a specific reason and its maybe not what a lot of people would put into it or choose, and being prepared to explain why it is that way before you come out is actually pretty helpful I think. Because what happens with a lot of things is that everybody kind of plus ones that feedback and you get lost in a sort of defense of it. So even if you can't fix it, you can at least be prepared to explain why it is and like maybe an example of this is...

• Philipp Dunkel ("Pip"): Time zones and calendars are both cases where that's the case, because most people that comment from the Western world, they don't see a reason why we should you add calendars. It's a perfect example for that. We need to be able to and we are able to stand up and say, 'Actually, that's a very limited view and once you do add calendars, that means you automatically have consequences from that, that might make other things slightly different.'

• Philip Chimento: Temporal.now and all of the functions that give you information about the environment that you are running in like the current time, or the current date, or the time zone that the user has set their computer to, they're all collective in this one Temporal.now object. I know the thing that people give feedback about, like how come to get the current date you don't just say new Temporal.PlainDate without no arguments. There's actually a reason why all of these functions that give you this information about the current state of things, that they're contained in this separate object. This has been a requirement since pretty early on in the proposal.

• Philipp Dunkel ("Pip"): The reason for that is SES. So there are secure environments concerns because whenever you expose information about the environment, you open up for fingerprinting it for security concerns. So in environments where JavaScript is used, that do have even higher security concerns where you want to basically hide all system information and make sure that system information is only available in a controlled channel. You need to be able to do that, and if you make the constructor with no arguments, take the current time, you have no way to basically say, 'Actually, you aren't supposed to have access to the current time.'How do you do that? So that's the reason why it was always considered, we need to put this into a separate place that secure environments can just remove.

• Philip Chimento: Its been requested since almost the beginning of the proposal that we separate those things out.

• Brian Kardell: So is it almost fair to say that there's sort of almost two proposals? There's sort of a proposal within a proposal when it comes to Temporal? Like one is the core language feature and then there's like how it works in a browser that has access to a lot more?

• Philipp Dunkel ("Pip"): Yeah, I wouldn't say that. Would you?

• Philip Chimento: I would actually.

• Philipp Dunkel ("Pip"): Okay.

• Philip Chimento: Because in the proposal text, there's a whole section of things that only apply to the Intl environment, so there are JavaScript environments that support this ECMA-402 standards for internationalization and there are JavaScript environments that don't, until there's a whole section of if you were a JavaScript engine that doesn't have any of that, and then this whole section does not apply to you. I think its fair to say that there are sort of two levels here.

• Philipp Dunkel ("Pip"): There are a lot of different concerns when it comes to the language as a whole. There are securities specialists in there that are looking at create a secure environment, and then there are browsers which are looking at, 'How do we do this in a browser? What do we have to ship?' And so on. Then there are environments like, 'If you think no chance in the server,' which has different concerns than it does of a browser, then there are engines like motherboard which basically have all the language in ROM and are intended to be used on IOT devices.How do you make sure that this doesn't kill that kind of engine. So there are a lot of different concerns that you actually need to address and get in that aren't as clearly apparent if you're coming at it from the perspective of 'I'm a web developer and I'm using JavaScript on a daily basis,' but they are still very important.

• Philip Chimento: So the example that you gave, motherboard, where everything has to fit in ROM, I actually don't know if they support internationalization but I'm assuming not. So if your engine doesn't support internationalization then there's only one time zone or one calendar in Temporal, where is if your browser-

• Philipp Dunkel ("Pip"): That's actually... I think its finer sliced than that because even if you don't support full internationalization, that cuts off all of the string formatting stuff. But you can still provide multiple time zones, even if you want to, even if you don't supply full international string formatting. So from that perspective you could say that there are five or six levels of proposals with access to local data, with no access to local data. With string formatting, without it. With time zones from where and with standard calendars from where. Most of this is dependent on the environment that you're in. Yeah, from that you could say there are multiple.

• Brian Kardell: So one of the things that we haven't talked about yet that I think would be interesting to cover in the last few minutes is when we're talking about what's happening in ECMA, ECMA didn't invent time, they didn't invent calendars, or time zones, or any of that. Like Maggie was saying earlier that if you want to get any of that right in Moment, it involves some pretty large bundles and things like that. So I was wondering if somebody could talk about the other standards and sort of how some of this works, and how do we even do that or know that?

• Philipp Dunkel ("Pip"): Well for one thing, we're differing a lot of things. So for example, for all string formatting, we're referring to the ISO 8601 standard. So we didn't come up with the string format, we use that and then we use the enhancements there and actually Ujjwal from Igalia went the whole way and made an RFC proposal to add the additional things we needed to that standard. Then for time zones, we're not saying that, 'Okay we're now specifying time zones and please include them,' we're differing that to the Unicode Consortium with IANA time zones, leaving that up to again something else. So that holds true for most of the proposal, is that we're trying to incorporate the rest of the world as much as possible.

• Brian Kardell: Its one thing to have words written down in a standard, an ISO standard, but lots of things have to deal with this and it's very complex. Who maintains this?

• Philip Chimento: Who maintains time zones? There's a database which is actually a collection of text files in a particular format that contain every known rule for when you go to Daylight Saving Time and when you go back to Standard time in every time zone. All of the current rules, all of the historical rules and these text files they're consumed by many different pieces of software, and there's all different pieces of software that compiles these text files into more compact binary representations or whatever.

• Maggie Johnson-Pint: It's worth noting that the IANA databases maintain not by computing people per se but by academics who are historians typically, and they get a lot of industry input, but the only reason I note that is that the text files themselves are worth the read. If you go read the raw text file, you'll see things like, 'This time zone changed due to the Nazi invasion of Germany in World War 2,' and which point, they are really quite fascinating, but anyways, keep going, Philip. I just want to call out that if anybody wants a little interesting history trip, it is in the flat files.

• Brian Kardell: Wait, while we're on this topic, I also have a sort of fun thing about this, which is to circle put a sort of book in my intro about history and things. Before the industrial revolution in America at least, in everywhere else in the world, I assume more or less is the same, like every town, basically had their own time zone. It was just sun time right? Like solar noon, you would have a timekeeper and that was your time. You can actually see these records in the Library of Congress and things where it would be a different time in Pittsburgh, Pennsylvania where I lived, and New York, which is very nearby and currently in the same time zone. Like whether they respected Daylight Saving Time or not, I guess was a decision that was up to everybody, like trains changed this because suddenly you could move faster than the sun, and now that became a problem because people missed their trains, everybody was confused. So when you say all of the historical data is in there, it is actually phenomenally complex history, and it's very, very interesting.

• Philipp Dunkel ("Pip"): Yeah. I mean there's a fascinating story with that, that I actually got from the IANA database files which is in 1786 or somewhere about then, the London Time Zone changed by seven minutes. Well, that's because the Royal Navy moved from Richmond in West London to Greenwich in East London, which makes the seven minutes difference in the Meridian. So from then on, London changed by seven minutes which is in that database file, which I think makes for really interesting cases or, 'I hate the year 1970,' because in 1970, which is the epoch year, so it's a classic one for testing.Well that hit me because in 1970, Britain didn't have Daylight Savings Time, they gave it a year off. Same during World War 2, they went to Daylight Savings, and never went back, and then the next year they went to another Daylight Savings and never went back. In the end, they were three hours different from where they should have been, and only afterward did they go back. That kind of thing is all over that database, and its really fascinating so I can highly recommend going into those plain text files and have some fun.

• Brian Kardell: These are databases that are in text files and we have different systems that build and use those and deploy them, and they have all sorts of different deployment strategies and update timelines and things like that. Philip works on our compiler's team and does a Momentation work and I was wondering if you could...

• Philip Chimento: Yeah sure. So a lot of the environments where Temporal is going to be implemented in, a lot of these environments are already have some sort of time zone database available to them because their browser already has time zone and already some connection to the raw database with these text files because it already knows about time zones in some form or other. So, not necessarily that you can directly call this information up through some sort of API but if you're implementing Temporal in a browser, and then you do have access to that information.It would be really prohibited if we recompile the time zone database into our own format, just using Temporal. We use what's already there which is generally goes through the ICU library, which also provides a way to calculate with calendars.

• Maggie Johnson-Pint: There's a PSA I got to slip in here. If you're a government official considering changing your time zone rules, there's a solid four to six month lead time for the database to pick that up and to be able to roll it out to all computers. Don't decide two weeks ahead of time. Governments sometimes do that and it does not work out.

• Philipp Dunkel ("Pip"): Yes, thank you.

• Maggie Johnson-Pint: Anybody listening who might be a government official.

• Philipp Dunkel ("Pip"): Yes please. Thank you.

• Brian Kardell: So we are just about out of time. Everybody, thanks so much for spending time with me here and talking about this. I think its super interesting, very exciting, and I really enjoyed talking to you all.

• Maggie Johnson-Pint: I guess on the closing, I would like to extend a couple of thanks. The proposal wouldn't be here if not for someone we haven't mentioned yet, which is Brian Terlson, who's been a [inaudible 00:43:01] in Microsoft forever. He met me when I had first joined Microsoft and was like, 'You're going to fix time, Maggie,' and he was very convicted about it. My closing though is I want to give a shout out to Brian Terlson for doing a lot actually to get this started, to help me get it started, and the other person I do want to thank is Philipp on the call for keeping me going when I got a little tired of the travel.

• Philip Chimento: I think for my closing words I'll mention the most hilarious response that we got to the feedbacks survey, which was somebody who filled out every question with a response, 'JavaScript is kind of cringe, why are you doing this?' That gave me a good laugh.

• Philipp Dunkel ("Pip"): Yeah, and on that note, I'll take over the shout outs because there are a lot of people that actually have been involved in this over time that have made major contributions. I'm thinking, as I've mentioned earlier, Justin Grant who came back with great feedback and very thoughtful comments that we recruited from the community, then Shane Carr from Google, who has been our interface to ECMA-402, who's been involved, and then, basically everybody that has been badgered by me or some of the other champions over the years for, oh, we need this from you. Can you give us an answer? Is this okay for you from the SES community, from Apple, Mozilla. I mean this is a proposal of a scale that it really involves a lot of people in a lot of companies spending a significant amount of time to move us forward. I think now is a good time to give them all a shout out. So basically, thank you everybody for tolerating the badgering that we've done over the years and helping us out where you could.

• Brian Kardell: Yeah, I guess on the note of saying thanks to people, I would say that if you haven't listened to any of our other podcasts, like a lot of the recent topics that we've been doing had been about the health of the web ecosystem and so they have been a lot also about who would invest, what they invest, and why they invest in this giant commons that makes everything about modern life possible. So I would like to say thank you to everybody who has invested anything in this and just to give a special shoutout to Bloomberg on this actually because they're someone that isn't a Microsoft or a Google and they contribute a lot to the patrolmans, so thank you for that.

• Philipp Dunkel ("Pip"): Yeah, and on that note, the person I forgot that I shouldn't forget because he's involved in everything and has over the years kept me sane and been a guiding light is little Dan, Dan Ehernberg. Again, he's been an enormous help in the standards context as well. So, thank you to Igalia for being great partners in this.