0

There is a HTML form in the client browser. The user clicks the submit button. An XHR is sent by JavaScript to the server then. The PHP knows the time of the arrival ($_SERVER['REQUEST_TIME']), but knows nothing about the time of submission. How could it be calculated precisely?

Community
  • 1
  • 1
Tamás Bolvári
  • 2,976
  • 6
  • 34
  • 57
  • 3
    Include a timestamp in the XHR request? – Pieter van den Ham Jan 13 '17 at 20:59
  • Good idea, thanks. I'm looking for a more precise way, that deals with incorrectly set client clocks as well. Is there a way to include a correct timestamp in the XHR, independent of the client's clock? – Tamás Bolvári Jan 13 '17 at 21:01
  • No, because you cannot trust clients to provide an accurate timestamp. – Pieter van den Ham Jan 13 '17 at 21:05
  • What if the timestamp is provided by the server on initial page load, stored on the client then, and sent back to the server finally? I only need to deal with the transfer time then, don't I? – Tamás Bolvári Jan 13 '17 at 21:07
  • I could handcraft a request to your server containing a timestamp of 2021 if I wanted to, that is what I meant. You can use @MacPrawn's answer, but you simply cannot _be sure that it is correct_. – Pieter van den Ham Jan 13 '17 at 21:09
  • Yes, you are right regarding the security aspect. But fortunatelly it isn't an issue in my case. The solution doesn't have to be unhackable, just precise. The problem with @MacPrawn's answer is that it is not only hacker-sensitive, but "incorrectly set clock"-sensitive as well. – Tamás Bolvári Jan 13 '17 at 21:13
  • Well the closest you might get is to check whether the sent timestamp is within an acceptable error margin, say 20 seconds. You will need to check that on the server-side. – Pieter van den Ham Jan 13 '17 at 21:16
  • I will try to get even closer, beacuse a 20 seconds tolerance isn't precise enough in my case. Thank you anyway Pete. – Tamás Bolvári Jan 13 '17 at 21:23
  • 1
    @TamásBolvári Anything done by the server will be the time that the server received the request, not the time that the client sent it. If you're trying to measure delay in the network, you need to have the clocks synchronized between the client and server, and get the client's timestamp. – Barmar Jan 13 '17 at 21:35
  • @Barmar Is it [impossible](http://stackoverflow.com/a/1942945/1293492) to sync them? – Tamás Bolvári Jan 13 '17 at 21:46
  • 1
    You can't sync them perfectly, but for most applications if you use NTP they'll be close enough. How much accuracy do you require? – Barmar Jan 13 '17 at 21:50
  • Like < 0.3 s. Thanks for the NTP idea, I'll browse some other questions, like [this one](http://stackoverflow.com/questions/8478179/synchronize-time-in-javascript-with-a-good-precision-0-5s-ntp-like). – Tamás Bolvári Jan 13 '17 at 22:07

1 Answers1

1

So as suggested, you'd want to add the timestamp to your XHR request as an additional URL parameter: 

"?sent_at=" + (new Date()).getTime()

The thing to remember is that javascript's dates are in milliseconds, whereas dates in PHP are measured in seconds - so you might have to convert the timestamp from the browser when you use it in PHP, something like:

$date = intVal($_REQUEST['sent_at']) / 1000;

If you really want millisecond precision, then you can use the submitted value as is - depends what you want to do with it.

Hope this helps!

nibnut
  • 3,072
  • 2
  • 15
  • 17
  • Thanks, it's really close to what I'm looking for, but I'd prefer a solution that works even if the client's clock is set incorrectly. Is that possible? – Tamás Bolvári Jan 13 '17 at 21:10
  • No, that will not be possible: you will be reliant on their computer's clock. I don't know of any serve-side variable that would hold the time the request was sent form the browser... – nibnut Jan 13 '17 at 21:12
  • What if the timestamp is provided by the server on initial page load, stored on the client then, and sent back to the server finally? I only need to deal with the transfer time then, don't I? – Tamás Bolvári Jan 13 '17 at 21:14
  • Well, that would give you the time the page was *sent* to the browser... I don't think that will help you get a precise time stamp for a subsequent XHR? I mean, you could grab the browser's date on page load, and then when you send your XHR, take your initial server time, and add to it the delta between the current browser time and the initial one you grabbed on load... But that will mean your XHR timestamps will be offset by the time it took the browser to run your javascript ... So presumably the network time to send your page back to the browser... – nibnut Jan 13 '17 at 21:19
  • Can you tell us why you`d like to know the precise time of requesting? Because Mac is right, you can never truly trust user input. You can add a get parameter to the request or simply read the request-time headers, but either way, the data provided can still not be trusted. – Merv Jan 13 '17 at 21:24
  • @MacPrawn I was ambigous, sorry. I don't want to simply send the server's initial timestamp back to the server. I want to use the server's initial timestamp to calculate the difference between the server's and the client's initial timestamp, so that these 2 clocks can be adjusted. E.g. you tell me it's 7 at your place, when it's 9 at mine when I start my breakfast, so when I tell you later that I've finished my meal when it was 10 at my place, we'll know that it means 8 on your clock. – Tamás Bolvári Jan 13 '17 at 21:41
  • @Merv Because I need to know if the XHR has timed out. If it has, the server should discard the request. Otherwise it should process it. You are right regarding the security aspect. But fortunatelly it isn't an issue in my case. The solution doesn't have to be unhackable, just precise. The problem with MacPrawn's answer is that it is not only hacker-sensitive, but "incorrectly set clock"-sensitive as well. – Tamás Bolvári Jan 13 '17 at 21:43
  • 1
    Right - so then that might work. But as I said, the time between your server sending the page, and the browser running it will not be accounted for. Should be minimal, but it'll be there. – nibnut Jan 13 '17 at 21:45
  • @MacPrawn You are right, that difference will be ignored. I'm not sure if it's minimal though, e.g. when the network speed is low and the latency is high. It could easily be 10 seconds, I guess. – Tamás Bolvári Jan 13 '17 at 22:01