System.currentTimeMillis() is a good choice for this?

I'm still not sure how System.currentTimeMillis() work, but I want to use it for a game server to handle Banned accounts.

For example, in data base I will have a "bannTime" which will equal (System.currentTimeMillis() + How_much_time_to_ban_in_ms ) in the user's data.

When the user will login, it will always check if it's OK using this:

if(bannTime==-1)return;

if(System.currentTimeMillis()>bannTime){
    // It's ok you can long in
    removeBanFromDataBase();
}else{
    // You can not login, you have to wait: (bannTime - System.currentTimeMillis())
    return;
}

What I need to know is:

Is it safe to use System.currentTimeMillis() like this as long as the code will always run on one machine ? Even if I reboot the machine, System.currentTimeMillis() will keep incrementing and never go back or start fr开发者_高级运维om zero ? Never ?

And what If I change the local time and date on the machine, System.currentTimeMillis() will change too ?

---

System.currentTimeMillis() will never reset to 0. It is the number of milliseconds since the Epoch, way back at midnight, January 1, 1970.

This approach is fine, and it's often easier to do maths with milliseconds, as you're finding out.

Ref: http://download.oracle.com/javase/6/docs/api/

edit: good point Spycho, the currentTimeMillis() response is based on the system clock, not magic, so changing the system time back by a couple of days would make the number decrease. But not in normal practice.

If you're using time to ban users, you will probably want to use an NTP service to keep your system clock correct (if you're not already).

---

System.currentTimeMillis() may go back (or leap forward) if the system clock is changed.

---

If this code is running on the server side you should be fine.

Due to leap seconds (or manual clock changes) the time on the server can change, but it shouldn't change by such a large amount that it actually matters if the ban is revoked too early.

You should, of course, ensure that the server is set to get its time via NTP, so that it's always as accurate as possible, and correctly set on reboot.

---

you could use a combination of that in addition to writing a file on the system and storing the timestamp/related information in the file

---

System.currentTimeMillis() is always the actual time, in milliseconds since midnight 1st January 1970 UTC, according to the local system. If you change the time on the machine, the output of System.currentTimeMillis() will also change. The same applies if you change the machine's timezone but leave the time unchanged. System.currentTimeMillis() will never reset to zero (unless you change the machine's time to be whatever the time was in the machine's timezone at 00:00:00.000 on 1st January 1970).

System.currentTimeMillis() should be fine for what you want to do.

---

You may like to set a `reboot counter (or program restart counter),' which is persistent (in db or file), to distinguish time-stamps recorded in different boot sessions.

And then record your time-stamp by the combination of System.currentTimeMillis() and the counter's value

When the reboot counters are different for two time-stamps, you may deal it differently from normal cases. Maybe launching a time synchronizing routine or something.

---

When using System.currentTimeMillis() you are getting the time of the System, in other words the time of the machine you are running your code on. So when you restart your machine, you will still get its time that will increment even when the machine is turned off for sure.

But when you change the time of the machine, System.currentTimeMillis() will get you the new time, the time you changed. So when the time is changed you will get wrong time.

I used this in many classes without holding the matter of changing the clock. You can just use it with only this risk. But I find it a very good choice to work on.

---

An alternative would be to use System.nanoTime() because a) its more accurate and b) its monotonically increasing. However its slightly more cumbersome to work in nano-seconds, and its highly unlikely to make any real difference, unless your system clock varies wildly by seconds or more. (In which case you are likely to have other problems)

---

just test this code. change time while running this code.

System.currentTimeMillis() stops printing out when system time is set back.

it starts printing again when time > time_before_setting_back

    while (true){
        System.out.println(System.currentTimeMillis());
        try {
            Thread.sleep(1000);
        } catch ( InterruptedException e ) {
            e.printStackTrace();
        }
    }