Like Warcraft of World, there is a clock to display the time of server rather than local time of the client.
How to do this?
If this can be done by server send only one package to tell client the current timestamp of server, then client based on this timestamp and goes tick on it, what if client have not a "reliable clock" such as Flash(clock will slow down when the FPS slow down)
Ok I don't know about World of Warcraft or their implementation. Taking average network jitter and delays into account you don't get a very accurate reading about time from the server. (That is why NTP is difficult.)
If all you want to display is the server time, you just need to send the server's time and add the current round trip time to get a rough but around 100ms accurate time. From there you use the systems clock. Sure the systems clock drifts, but we are talking a few seconds a day at worst.
If you are thinking about actually using the servers clock for more accurate time reading or logic, I would strongly discourage you from that. You should use the local system clock as time of reference and work with time deltas based on that.
I am not sure what you mean by reliable clock. Everything above 1s is handled by the system clock with is a separate timekeeping IC which runs of of a quartz, like any other clock. Anything below 1s runs of the CPU ticks and they are very reliable, the CPU would not work if it was not the case. We are talking picosecond accuracy. You get reliable time readings down to 1ms easily. Just so I don't get grilled for it, the system clock IC actually runs more acuratly and the CPU uses that to sync up it's tick rate, wich is a multiple of the system clock tick.
So why does the time slow down while low frame rate? Do you mean simulation time as opposed to real (wall) time? In that case you have other problems to handle, like what happens when different clients have different time dilation. But the way I see it is that the server is the only authorative instance and the client only do prediction. The prediction is off by multiple 100ms anyway through network jitter, so time keeping is the least problem. It also helps to make client prediction and effect simulation frame rate independent. Sure it reduces accuracy, but on the client any simulation should be only for a smother experiences.
The packet to update the clock doesn't need to critically match the FPS of the client. Depending on the network protocol, or the packet structure itself, it would be enough to send a tick once every second. In most cases, the timestamp of the packet itself can be used to match the second tick of the server.
So, async or sync packets who have a timestamp, where the part identifying the "second" can be used to inform the client. Even if there are multiple packets sent each second, any of them can be used to extract the timestamp of the server.
There doesn't need to be a specific time update packet from the server each second, is what I'm trying to convey.
Generally the server clock is there for convenince to the user so being out by 30 seconds to a minute is not so bad.
If your building a game with say 1000 users, the last thing you want to be doing is sending 1000 NTP style messages every second or minute (unless you want to be super accurate).
Seeing as every computer has its own clock. When a user logs on, you can send your own time to the user, determine the offset between the server clock and their clock. and then just use thier clock + the offset to show the server clock.
I would not use timezone calculations as a clients computer may be fast or slow or just wrong. however if you calculate an offset, unless they go and change their clock, it will always show the correct time.
According to Adobe, Flash has a "Date.getTime()" function which returns the current local time, as set on the computer running the Flash application.
This should make it trivial to show the server time, regardless of frame rate or other factors. When you know the server's time, subtract the local time from that in order to know the offset from local time to server time. Then whenever you want to know the server time, you can just add that same offset to the local time. Frame rate doesn't come into it at all.
