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.
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.
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?
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?
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.
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.
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.
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: 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.
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.