Time is a construct but it can still break your software

Time is a construct but it can still break your software - Stack Overflow

Stack Overflow Business Stack Internal: the knowledge intelligence layer that powers enterprise AI.Stack Data Licensing: decades of verified, technical knowledge to boost AI performance and trust.Stack Ads: engage developers where it matters — in their daily workflow.They explore the current flaws and issues in JavaScript that make the Date object so hard to work with, how libraries like Moment.js helped but eventually became too complex themselves, and why the Temporal proposal took nine years to complete.Temporal is a new TC39 proposed standard for JavaScript that replaces the Date object. It operates as a top-level namespace and brings a modern date/time API to the ECMAScript language.Connect with Jason on Bluesky or at his website.Congrats to Great Answer badge winner BrenBarn, who won the badge for their answer to rethrowing python exception. Which to catch?.TRANSCRIPT[Intro Music]Ryan Donovan: Hello everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we're talking about time, JavaScript, and the Temporal proposal that is looking to be incorporated. My guest for that is Jason Williams, senior software engineer at Bloomberg and the creator of Boa, a Rust-based JavaScript engine. So, welcome to the show, Jason.Jason Williams: Hey, yeah, thanks for having me.Ryan Donovan: My pleasure. My pleasure. So, before we get into talking about time, give us a little insight into how you got into software and technology.Jason Williams: Yeah, so I've been a software engineer myself for quite a while, probably over 15 years. Could probably come up to 20 years, now. I've been at Bloomberg for around seven years. Before that, I was at the BBC, a broadcaster in the UK, as a senior software engineer working on the BBC sounds product. And yeah, even going further back than that, I was involved in some open-source projects. I was actually trying to find one of my earliest contributions, and I think it might have been jQuery back when John Resig was running the show, and it was around 2010, and I think I was trying to fix a bug with click events. And Interesting, it's related to this actually, because when I was going back and looking through that book and the conversations. So, obviously, it predates GitHub a little bit, but you still have the comments when somebody did a patch and all of that.Ryan Donovan: Right.Jason Williams: And actually, one of the people who commented is someone who is a Temporal champion. So, it's a small world.Ryan Donovan: Yeah. I keep seeing this being talked about. And in your blog post about it, you mentioned it's taken nine years to get this moving. First of all, I wanna talk about it: why is time—date and time—so difficult?Jason Williams: Yeah, that's a good question. I think there are so many approaches that people can take. And I also think it depends on your audience and who's using it, as well. For instance, when JavaScript first started out, back when Brendan Eich was working on his sort of prototype of what we now know of as JavaScript. I think then it was quite easy to just take something quite basic, take something off the shelf. He probably didn't foresee that we were gonna end up with these huge JavaScript applications that needed to know things like time zones, or calendars, or anything like that. I think back then it was like, 'hey, here's a basic date object,' and that will do.Ryan Donovan: And he knocked out the precursor to JavaScript in 10 days. A 10-day sprint.Jason Williams: Yeah, that's right. And I guess a lot of that was because he was able to just take what Java's APIs were doing and do a wholesale port over into JavaScript. So, that made life a lot easier. They didn't have to sit around and come up with API design. It was, ' let's just take these things.'Ryan Donovan: Yeah. So, date and time [are] things that people take for granted, as like, it just works, right? But we've had a conversation on this program with Jon Skeet about how complicated it is. And we've obviously had the Y2K issue, and we may be coming up on the apocalypse with the Linux State and time. But I remember at my last job, people sitting up when there was a time zone change, when there was a daylight savings change, just making sure everything went correctly. And you talk about a lot of the little things that you would expect to work correctly that just don't. Are these things that you think showed their wear and tear because JavaScript became more of an enterprise language?Jason Williams: Yeah. One of the things that I mentioned in the blog post is how the web grew up. But the date object [in] JavaScript stayed the same. I think there's definitely an element of that. One of the biggest flaws, I guess, most people would describe in date is the mutability factor of it. I think if you go back, I dunno, 20 years ago, some small applications hit that bug, but it wasn't really deemed as a big deal then. A lot of things were mutable, a lot of applications running JavaScript are only doing very small changes to a website, changing the color, or reacting to a click input. And then, I guess as we started, it hit the sort of corporate world as these applications got bigger, and were used a lot more places. These bugs that started off being trivial were actually quite important, and [were] causing a lot of problems.Ryan Donovan: And I feel like the date being mutable is one of those bugs that you don't really understand until you run into it.Jason Williams: Yeah.Ryan Donovan: Can you give an example of what this looks like in practice?Jason Williams: Yeah. So, the API of getting and setting a date is: you have a date object, and if you wanted to, say, get the day, that is just calling the day object, 'dot. Get date,' which is not the best name in my opinion. I think that's another issue with the date object. The name's a bit vague. It's not really clear what sort of type that's giving you back. But setting, you can also have 'set date,' as well. So, you have ‘get date’ and ‘set date.’ You have a lot of pairs like this. And what people tend to do is, when they want to return a new day of that date, they often call 'set date' and then pass in 'get date +1,' or +2, or whatever, or -1, and then return that value. But 'set date' will also mutate the current date. So, people often ended up trying to return the new date, but also setting the current date that was passed in. So, you ended up doing two things. You were giving back a new date, but also setting the current one, and that's the trap that a lot of people often fell into.Ryan Donovan: If you wanted to calculate something for a future date, you'd accidentally change–Jason Williams: Yeah, exactly. Yes.Ryan Donovan: It's cheap time travel, right?Jason Williams: Yeah. Exactly. So, a lot of these things change in place. I think if you look at JavaScript today, a lot of newer APIs, and a lot of newer proposals don't tend to do that as much. You'll probably notice that, these days, things that change in place is quite rare.Ryan Donovan: When people started noticing this, a lot of the sort of fix for it came through libraries. Can you talk about how that worked, and what're the sort of flaws in that approach?Jason Williams: Yeah, so I think once we reached that era when– so Node.js was born in around 2009, and then we started seeing things like NPM, and not just NPM no, but people just sharing scripts. I can remember adding script tags to the top of your page from random SourceForge endpoints or wherever. But we started to see libraries tackle this. I think Moment.js was certainly the biggest example, and I think it went out because, one, it was one of the earliest, but also because the API was quite straightforward. People understood it. It made sense. They had good documentation quite early on. So, most newcomers were able to come to Moment.js' website and understand what these things are doing. So, it took off in a big way. I think, actually, Moment also gave you the idea of these sort of types, as well. If you call this, you are gonna get this sort of value back, and then with that value you can do these things. The problem though, started to, I guess become more apparent when websites were becoming a bit more bloated, and it wasn't just Moment.js, to be fair. Once you went from around 2009 to 2016, 2017, you did start to see more and more libraries become quite huge. And Moment had a lot of data packed in with it. So, it needed locales because it did date formatting. So, taking a particular date, and formatting it to a certain locale. But also, time zone information as well is something that Moment.js supports. To be fair to Moment, I think they offered a way to strip it out if you weren't gonna do any sort of datetime arithmetic against various time zones. But a lot of people did use that. So, we started to see huge sizes in these datetime libraries. Moment was one of them, but you had other libraries that were also doing the same thing. And these sizes were massive. You could cheese at these libraries down to 150, 200K. But that was still a big chunk that people were having to download all the time when using those various apps that were using Moment.js.Ryan Donovan: And for a lot of places [that] have slower internet still, that 150-200 K is a pretty big lift, right?Jason Williams: Yeah, absolutely. And developers were raising this on Moment.js as a GitHub repository. Is there anything we can do about the size? I think Maggie Johnson-Pint, who was one of the maintainers of Moment.js, among others. I think I recall her going to some conferences, and one of the first questions that people would raise to her was, 'how can we bring down the size? We love Moment.js, it's a great API, but it's just way too big. We can't really be shipping this all the time.' And so, I think, yeah, there's only so much that you can tree shake.Ryan Donovan: Yeah.Jason Williams: They don't know ahe