debug: display format for time.Time

[alialtun14]

The value of time.Time is displayed as follows.

time.Time {wall: 0, ext: 63775987200, loc: *time.Location nil}

Could it be converted the display format to a readable one?

[hyangah]

Either evaluate from the DEBUG CONSOLE (call mytime.String()) or register the evaluation in the WATCH panel (example)

Let's use #158 for more than that.

Delve's call feature involves non-trivial complexity behind the scene (and AFAIK it is still classified as an experimental feature), so calling that for all the time.Time type variables automatically can be risky.

[polinasok]

This was an issue in delve repo. And I made the suggestion that this could be filed as an issue against vscode-go for us to consider adding a human-readable child as we did for bytes because this is not the first time our users requested help inspecting time vars.

[hyangah]

That's possible only if dlv (and dlv dap) can reliably handle call. Until then, I don't see anything that can be done from the extension level. #158 is the general improvement feature request. If dlv can offer special expr evaluation formatting for time.Time or some well known types without going through the hoop of call, that will be great, but that's dlv issue.

[polinasok]

We have been historically tracking/triaging dlv-dap issues (as experienced via the vscode UI) here as opposed to the dlv repo even though the changes were to be made to the dap server in the dlv repo. We can revisit that if you think these things are better tracked in the delve repo from now on.

#158 is so general (especially the customizable part), I don't see us working on that that any time soon. I think that's why we chose to special case bytes. I don't think we would want to use call, so we are in agreement there. But I thought maybe we could explore reconstructing time from the raw wall clock or whatever is stored in the struct itself.

[hyangah]

But I thought maybe we could explore reconstructing time from the raw wall clock or whatever is stored in the struct itself.

That is the approach I am getting at and I think that's generally helpful for all delve users if implemented as extension of dlv's expression handling, not just for DAP users.

--
(EDIT) I am reopening this issue in case you plan to implement a DAP specific solution. Given that the original issue was reported as a general Delve issue, I hope the solution is available to general delve users and application beyond DAP, and the original issue is a better place to start the discussion among Delve devs. For example, if the solution could be available from the delve expression level, that would help users of watchpoint, display, and even just print command.

[polinasok]

My understanding is that the original issue was prompted by a debugging experience in VS Code, hence the redirect.
But, yes, I agree that it would be nice if such a feature was available easily in any delve client.

EDIT: Looks like this idea was already shut down in go-delve/delve#999.

[hyangah]

If the only way to implement this is through call, I am also skeptical about automatically formatting time.Time.
If you plan to implement this bypassing call but interpreting the raw data directly, note that time.Time internal can change across Go releases (there is a precedent).

[hyangah]

Closing in favor of go-delve/delve#999 which is now open again - we just need to make sure the new presentation is used in variables and evaluate requests.