Timestamp the initial message, player 2 takes a diff and sends it back.

If there are simple ways to get unidirectional latency, I will use it because it's closer to what I need.

Simply, there are not.

There are complex methods to get it. There are expensive methods to get it. For example, you could synchronize two atomic clocks and move them to the different locations and use those to compare the difference each direction, including accounting for dilation of time as you moved the clocks from one place to another. Or you could determine the exact distances of fiber cable and distances of copper cable and the exact devices in the middle, then run though some complex equations.

Far easier is to just find the round trip and divide by two. This is close enough for most things.

Note that what matters is that all players see the same events in the same sequence/order -- not the exact time at which they see the events. You need a monotonic clock for your simulation, but the clocks don't actually need to be exactly in sync, and trying to make them in sync is hard, and gives no extra value.

It depends on what sort of game you're making and what exactly you're trying to do with it. Motion prediction and other anti-lag features for fast-motion real-time gaming (which Abraham did say he was trying to do) do very much require knowing precise timestamps to do properly. Just knowing the order of events usually does not work well for this at all.

As for the original question, however, do note that for these sorts of calculations, it seems at first like you would want to know one-way latency, but really when you do the math it all comes down to round-trip-time for almost all of it anyway. The important point is not whether the client screen exactly matches the server's state at a given absolute time, but that the server's idea of when user input happens matches up with the same server state as what the the screen showed when the user made the action. If you predict-forward just based on the one-way latency, then the client screen will (theoretically) match up with the server state (to some impartial third-party), but when the user does an action, you still have the latency to send the action back to the server, and when the server receives it, its state will be different than what the user thought it was based on the screen image when they pressed the button, etc.

So you actually would want to predict a full round-trip-time ahead, so that what the user sees on the screen matches (as best it can) what the server state will be when their action finally makes it back to the server.

Also note, however, that the further you try to predict ahead, the more error you will inevitably have in your prediction, which is why a lot of networked games attempt to handle this other ways (or do it only partially this way, with other compensating measures as well). As just one example, you might want to take a look at the "Lag Compensation" section of https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking to see how the Source engine does it (which is basically to have the server look into the past instead of trying to have the client predict the future), etc..