16:01
<styfle>
Now that we almost have Temporal, has anyone tried to write a proposal for something like await sleep(d: Duration)?
16:09
<bakkot>
The binding constraint there was never Temporal, it was having more exposure to actual clocks in the core language
16:10
<bakkot>
Also the conflict with scheduler.wait, now
16:12
<Chris de Almeida - upcoming OOO: Oct 10-14>
namely, setTimeout is not in the language, which is what idiomatically is used for pause/sleep
16:15
<Chris de Almeida - upcoming OOO: Oct 10-14>
similar story with observables
16:48
<Mathieu Hofman>
The lack of time based scheduling actually runs deep and is leveraged by things like Worklets on the Web, which are agents without an "event-loop" (only promise jobs)
18:03
<styfle>
Hmm, so maybe a better path forward is to propose a change to setTimeout in the html spec so that it accepts Temporal.Duration? Or maybe there’s an easier way to just convert Duration to ms already?
18:16
<bakkot>
yeah Temporal.Duration.from({ hours: 130, minutes: 20 }).total('millisecond')
18:16
<bakkot>
as long as you don't need a week or more
18:17
<bakkot>
but yes you could also change setTimeout
19:05
<styfle>
Thanks! Can you explain the “week or more” caveat?
19:17
<bakkot>
https://tc39.es/proposal-temporal/docs/duration.html#total
19:17
<bakkot>

Interpreting years, months, or weeks requires a reference point. Therefore, if unit is 'year', 'month', or 'week', or the duration has nonzero 'year', 'month', or 'week', then the relativeTo option is required. For this reason, it's required to use the object (not string) form of totalOf in these cases.