Nice catch. Probably just a timing issue, but worth getting on the to-be-polished fix list.

Yup. That's where the bug is. They did not correctly synchronize the local timer to the server clock or, worse, are using the local clock instead of a timer.

All is needed is a few small packet exchanges when the client starts. Hardly a traffic issue.

Not really...
Your client is subject to lagging, therefore the time counted by your client can be quite off from the server time after playing for 2 hours for example. I encountered that while coding my own game back in early 90's (computers weren't as fast back then as they are now :-)) but seeing as Perp client lags to Hell and back even on my machine I suspect the internal timer lags just as well.
Solution:
1. On client start sync client time with server time using NTP
2. Upon syncing the client sets a constant "offset" variable which is the result of the equation of [Server Time - Client PC BIOS Time]
3. Every 15/30/60 minutes the internal time in client syncs with server again by setting client time to [Client PC BIOS Time + offset]
No network traffic and the client stays more-or-less synced. Please note that BIOS time is hardware-controlled and therefore not subject to lag (however, it's subject to hardware issues that can make it go +/- but only by miliseconds really)

Client lagging has nothing to do with clock drifting. Clock drifting on modern hardware should be absolutely negligible even over a long playing session. In any case it can be measured and corrected for. Also re-syncing requires such a small number of bytes on the net that they could just re-do it periodically.

Anyway I just noticed that the client actually does get the server time already, but it increments the "available" EP count on the minute of the client clock, not on the minute of the server clock, so this is actually a bug and it should be pretty easy to fix as the server clock is already available to the client.

Extra hint: intentionally offset the server clock value, as kept on the client, by one second (or a fraction thereof) and update the EP count on this offsetted clock minute instead of using the client clock as is currently the case. There'll never be this problem any more, you do not even need to care too much of precise syncing, jitter, systematic bias due to differing forward and backward routing, drifting etc. etc.

They display rounded down. And if they require more than what is actually displayed, that is a bug (a different one).

There however is a bug with the clocks. Not a synchro bug, but the client is updating the available EP count when the local clock times the minute instead of updating it when the server clock times the minute. Since the client already has both clocks available, there's no reason not to use the server one instead of the local one.

Once they fix this and use the server clock instead of the local clock, then a sync problem may surface. But that's easy to fix too (my suggestion being to intentionally set the server clock, as kept on the clients, one second, or a fraction thereof, later than the actual server clock).

Yep. It is somewhat synchronized, but it's not über precise. Anyway as long as they change the client to update the available EPs according to the server clock and they make sure the server clock, as kept by the client, is not ahead of the real server clock things will be allright. Small differences between the server clocks of different clients are not a problem, as long as they are all are behind or identical to the real server clock.

1) we are not talking of synchronizing the game (nearly impossible due to lag and jitter), but of synchronizing clocks (possible up to the 1/2 of the systematic difference between up and down packet routing times).

2) to solve the problem the OP has seen we do not need exact synchronization. All that is needed is that the server clock on the client is guaranteed not to be ahead of the actual server clock (and this is the easiest thing to do when handling remote clocks, you do not even need a synchronization formula or protocol).

+1 to Annihilator.

That's why you should use the hardware clock and not the OS clock. But I agree that windows may be stupid enough to update the hardware clock with borked OS values.

Anyway there are multiple solutions for that too. Also an MMOG by definition is networked at least to the game server: resyncing requires just a few bytes.

Besides: the client is updating the available EP count according to the local clock, not according to the server clock despite the fact that it does have knowledge of the server clock. THIS is the bug.

While entertaining this is extremely slow and reliant on the response time of the handling interrupt.

What are you talking about?  HPET doesn't replace the RTC for time tracking,  in fact  it has nothing to do with determining UTC time at all, its an interrupt timer for triggering events.