"the time, in seconds, it took from the start until the SSL/SSH connect/handshake to the remote host was completed". However, seems that when cURL has to open a new TCP connection and the protocol is plain HTTP the reported timing is just 0.

Which is because there was no "SSL/SSH connect/handshake" performed so it never stores any appconnect timestamp then. In the case of reused connections it always stores it since it then doesn't check if the existing connection uses SSL or SSH...

But yeah, maybe we should avoid the zero case and instead just have that use the time_connect time.

Exactly, it's just a matter of consistence. With recycled connections (either HTTP or HTTPS) cURL already behaves like that, and I am calculating the actual SSL handshake time by subtracting time_connect to time_appconnect. I noticed the inconsistency because I was seeing negative timings when doing this subtraction while performing HTTP requests.

This doesn't seem like a bug to me or I don't understand the issue. time_appconnect is documented for the "SSL/SSH/etc" [1] handshake and there was none. How about it's wrong for appconnect to be anything other than 0 on a reused connection.

[1]: Note that time_appconnect maps to CURLINFO_APPCONNECT_TIME in libcurl which doesn't have the "etc".

Ok, let me try to elaborate this a bit more (sorry, not a native speaker). My point is that for HTTP requests time_appconnect should always be either exactly 0 or equal to time_connect to be consistent, but not both like in the second sample run.

As far as I know all time_* variables report the time elapsed since the beginning of the request until some operation or stage of the request lifecycle completes. It also seems like the "TLS handshaking stage" (either if it's actually done or not) is something that happens between time_connect (establishing the TCP connection?) and time_pretransfer (cURL ready to push the request bytes over the wire?), because time_connect <= time_appconnect <= time_pretransfer usually holds true. The documentation for curl_easy_getinfo also depicts the different time values like this:

curl_easy_perform()
    |
    |--NAMELOOKUP
    |--|--CONNECT
    |--|--|--APPCONNECT
    |--|--|--|--PRETRANSFER
    |--|--|--|--|--STARTTRANSFER
    |--|--|--|--|--|--TOTAL
    |--|--|--|--|--|--REDIRECT

With this understanding, on my system I was relying on time_appconnect - time_connect to log an approximation of the time actually spent inside the TLS handshake, and expected to get a correct result regardless of the protocol. But then I started to see negative "TLS time" records for some HTTP requests (later I found these were the ones that create a new TCP connection, due to 0 - time_connect), and the correct 0.000000 for most others (the ones that managed to reuse a connection). That's the issue.

I believe this has been addressed since #3773 was merged. Can anyone confirm?

What I fixed is different from what he reported which is why I ref'd this rather than closed it. Basically in a nutshell he expected appconnect to always be greater than connect:

on my system I was relying on time_appconnect - time_connect

In my opinion though the diagram may infer that we have it documented correctly, "The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed."

therefore it may be 0

Yes, it hasn't been fixed the way I hoped but in master the time reporting is now consistent (in the original example now both plain HTTP requests will report APPCONNECT as 0.000000, instead of both reporting the same timing as CONNECT as I wanted).

I think the disagreement stems from the fact that I think of CONNECT, APPCONNECT, PRETRANSFER etc. as "stages" of curl_easy_perform() that are always executed in the same order, even if they don't involve any work (because of the diagram from the documentation that I pasted above), whereas you both think of APPCONNECT as just an "operation" that may or may not happen, so then it makes sense to leave it at 0 when it's not done at all.

This is now consistent.