Bobbe

But wouldn't the function work similarly to the `action_` functions then? [Here](https://www.klipper3d.org/Command_Templates.html#actions) it states that: > these actions are taken at the time that the macro is evaluated, which may...

Thanks, that makes sense. In that case here's a new PR: #6010

> it seems a bit "esoteric" and I'm not sure it is worth the additional code and documentation complexity Do you mean the general concept of having a `unixtime` like...

> And it should be clear that I still do not consider this as part of Klipper's core competency Even if it's not, what's the problem with having it exactly?...

@pedrolamas > I do wonder if this would be better as a function (set on PrinterGCodeMacro.create_template_context, just like action_emergency_stop and others) instead of a static variable injected into the script...

A possible alternative would be a self caching function I guess.

That'd atleast allow for the functionality to be implemented at all, I think I'd still prefer a direct timestamp without the unnecessary calculations, but yeah. Regarding naming `estimated_print_time` print time...

In that case `last_print_start_time` and `last_print_start_ostime` would have to already been set at mcu startup (with `idle_timeout.printing_time` this wasn't the case iirc), otherwise you'd first have to start a print...

What about changing `last_print_start_ostime` to `mcu_startup_time`/`mcu_startup_unixtime`? Basically instead of having a unix time stamp for every print start, having one for the moment the mcu started up. That'd make the...

I reimplemented the functionality with the discussed changes.