Michael Klement

@iSazonov, I agree regarding the concerns about the breaking changes, but let us take a step back: Conceptually, we are dealing with two modes of termination: * _Cooperative_, via signal...

@iSazonov, I agree regarding the issues _not_ to discuss here; it is exactly why I called them _asides_: something to perhaps inspire a separate discussion, though I get that that's...

@iSazonov: On a meta note, I think at this point it is clear that before implementing anything we need to write up a _new_, focused proposal, following this discussion. Therefore...

Thanks, @iSazonov, but let me spell out the implications of your proposal, from which I conclude that it is _not_ worth implementing as such: * The behavior will be inconsistent...

Thanks, @iSazonov - good find, and I do think that starting small is an option, but let me flesh your suggestion out to see its full implications: * Existing `Stop-Process`...

> it makes no sense for us to try to do something too clever I was proposing the very opposite: I was proposing to simply use the underlying platform feature,...

@sba923, `ConvertTo-Json` in v6+ creates a `[datetime]` instance with a `.Kind` value as follows: * `Unspecified`, if there is no time-zone information in the input string. * `Utc`, if the...

@sba923, thanks for opening the docs issue. Note that the new `System.Text.Json` API that is being considered as the future underpinning of the `*-Json` cmdlets - see #11198 - exhibits...

@sba923, I've created a feature request for a `-DateKind` parameter for `ConvertFrom-Json` that would solve your problem: #13598 I think you can therefore close this issue now.

Let's take a step back: **Use of `[datetime]`:** * `[datetime]` has several inherent limitations: * It only specifies an _absolute_ point in time if its `.Kind` is `Utc`. * With...