NGINX request_time starts when the first byte of the request is received in NGINX and ends when the last byte of the response has been sent to the local NIC (i.e. network adapter). By, local, I mean local to the machine where NGINX software is running. The NIC then sends the request packets down to the client. So, NGINX request_time doesn't technically include all the time "sending the request to the client". That wording is a bit misleading.

However, my team uses request_time - upstream_request_time to get an approximation of client network issues because, while request_time doesn't reflect much of the response time, it does reflect some of the request time. NGINX request_time includes the time between the first and last byte of the request being received and on a slow network connection, this will be slower.

So it could be imagined like this:

Client gets a socket (e.g. TCP)
Client sends handshake
Handshake goes through local network and proxies
Handshake goes across internet
Handshake reaches edge of server network
Handshake gets to NGINX - request_time starts
Rest of HTTP request goes up to NGINX
Last request byte received in NGINX
First byte of request sent to upstream server (e.g. Tomcat servlet) - upstream_request_time (URT) starts
Upstream server handles the request and sends back a response
Last byte of response received from upstream server - upstream_request_time (URT) ends
NGINX sends response through kernel buffer to NIC - this is usually nearly instantaneous
Last byte sent to local NIC by kernel
NGINX finishes writing to log file - request_time ends
NIC sends response to client
Internet
Local network: proxies, routers, switches, etc.
Client receives last byte of response (NGINX has no idea about when this occurs. To measure this you'd need to implement something in the client side of your application. For example, assuming your client is a browser application, see https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/responseEnd)