Wont all updates received by the client be in the past?

Only if the client immediately applies commands before sending to server. This is a legitimate strategy, and the server (and other clients) will have to then back up and re-simulate their physics. (The "counter-strike" model does this, but only for shots/damage)

An alternative is to have the client time-stamp commands for the future, and then actually apply them in the future. There will be a small command lag, and your job is to hide this lag through UI. RTS games will do this by playing a "yes, sir!" animation before starting to move.

A third option is to just run commands in the order received on each node. Where there are disparities, just apply them as-received, and wait for the server to correct you. The server will then have to send periodic "baseline" updates for the state of each object, such that correction can happen. You'll probably want certain effects (death, falling off cliffs, etc) to only happen when the server says they have happened, rather than pre-simulating them on the client, for best consistent display.

For a gameboy-pokemon style RPG, the last option may be perfectly adequate. You still want a different update rate for network packets than for input and simulation, though. And, when commands are received, you put them in a queue, and run something like one command per player per physics tick. (Where "physics" really means "simulation.")