On the contrary, "time box" means the time is fixed, the work achieved is variable.
Projects: the project comes in "on time and under budget" or is "late", but the work is fixed.
Time boxes: The difference is if you are targeting an RoE curve, you can decide when to continue investing in that or pivot to something else. You pick a date to re-evaluate. This is how VC work with startups.
You also make sure have minimum viable outcome well before that re-eval date, and then viable increments. It's effectively just CI/CD for outcomes!
I should mention that by running a video streaming VDN, in the 00s we carried the world's largest streaming events white labeled for other CDNs. TV deadlines are real: the Oscars, or the State of the Union address, are happening when they happen. So you can have to deliver outcomes in a time frame. The way to always always hit that, never miss it, is let the work within that outcome, the "definition of done" be the variable. Somewhere inside the effort is a minimum viable outcome. Ship that, then iterate until your date or additional effort is below your RoE bar.
Managers love to invent deadlines to "motivate" a team, and everyone pretends they don't know the deadlines are nonsense. Actual deadlines -- if you're not working, you're dead -- teach you a different way to work.
A project tries to fix both work and date, which doesn't work and is rarely on time.
A time box fixes the date, not the work. Iterative delivery always hits the date and generally works.
---
Using your weekend desk example:
You could want a wood inlay desk.
For the "job to be done", the desk has to support you doing work.
In this toy example, the wood inlay is a desired constraint, not a required constraint. Business analyst will still call "wood inlay" a requirement, even though that "requirement" might lot let you ship a viable desk within the weekend.
If you do the work project style, you might work the wood inlay for each panel before assembling them into a desk.
The problem is, until you assemble it, the desk isn't a desk, it can't do the job to be done. If inlay takes longer than you thought, because it's your first time doing it and you had to research and built a couple test panels to throw away, then when the weekend is over, you have no desk.
If you do it time-box style, and if "usable desk" is the required constraint, you might assemble the desk first, then do the inlay. Or you might design the desk where panels can be removed and inlaid whenever. Either way, if you ran out of weekend, you can already use the desk, just not fully inlaid.
Certainly, doing the inlay after assembly will require more effort.
So then ask yourself, was the deadline real, or was the inlay requirement real?
If you know in advance that desk with inlay is the absolute requirement, you're willing to take two weekends instead of one, so then the deadline wasn't real.
---
What's funny about this is, within a firm, everyone would jump on me and say the desk and the inlay are requirements.
But if you don't know how to build desks, and need a vendor to provide it, you suddenly become tolerant of the differences in soft and hard requirements.
Say you have to work from home, and you want a desk with inlay, but can't get one in time. You will iterate instead!
You'll work at a table (the minimum viable desk) immediately and for a while, then maybe iterate to an Ikea desk while the custom one is ordered and hand crafted, then iterate to your custom desk with inlay when it arrives, with the added flexibility of arranging shipping to deliver when it's most convenient.
If we handled work among groups internally the same way we understand we have to handle work among groups when we can't control them, companies would have a lot less jank.