How get accurate UTC timestamp in android

Question

I do not know which one is right for get UTC time

My code is

System.currentTimeMillis()

for java android

Is the result correct for international?

Maybe user can change device time and result be different? (Does it affect on UTC?)

Answer 1

On Linux platform, the system clock should be set to UTC. Whether it actually is, and whether it is accurate, is ultimately up to the user.

Calling System.currentTimeMillis() will give the time in UTC since 1970-01-01T00:00:00Z.

Is the result correct for international?

Yes. Provided that the clock is synced with a decent network time source and the user hasn't messed with it.

Maybe user can change device time and result be different?

Yes they can. There is not much you can do about it.

You could attempt to connect to a network time server, but the user could block that, or cause your game to connect to a fake time server. If they "own" the platform that your game runs on, you probably have no way to get guaranteed reliable time.

(The Wikipedia page on NTP talks about man-in-the-middle attacks. Unfortunately, standard NTP doesn't have a way to deal with that. There is a draft RFC for Network Time Security, but they have been working on it since 2015, and it still hadn't concluded at the time of writing.)

Answer 2

There is a common misconception around getting the correct "local" or "international" time. Time itself is unaware of these concepts, and I'll try to give an explanation here since other people still search for it.

Note that the following applies assuming that the machine clock is accurate in counting time, and initial time setup at boot was also correct. Also note that most connected devices will sync this internal clock with a network source from time to time to make it run accurately.

Time itself is something we don't control, it passes along one moment after another. But time presentation (seconds, hours, days, years, decades) is a human-created concept, made simply to understand the passage of time more clearly. You can imagine the confusion if we discussed time in moments - "Hey, I'm going to the store in 901400203150 moments, would you like to join?".

Anyway, the same is true for time zones, they are a human-created concept. We live on Earth, near the Sun and the Moon, and there is some revolving happening in space that made us recognize a longer time period called "year" and shorter ones called "month". We also recognized that morning comes earlier in some places, and later in others - thus, we introduced time calculations and time zones to make time tracking easier for everyone on the planet. But 10000 years ago, nobody knew about time zones, and yet time was passing by.

So, to answer the original question with that in mind: yes, that method will work, if you're interested in getting the absolute current time.

As mentioned, there is no such thing as "international" or "local" time, time is the same for everyone. We use these terms when referring to time value converted to and presented in a certain time zone format. Today we have something called Epoch (for humans: 00:00:00 UTC on 1 January 1970, for most machines: 0) - so fetching "milliseconds since Epoch" will give you the amount of raw time, expressed in milliseconds, passed since Epoch.

Time itself does not know about time zones or years or months, this is a human construct that you have to convert to on your own. Basically, what you get from the OS is raw time, and then you convert it to the desired time zone, desired format and language, to make it easier for the user to read. And how to convert time - that's a completely different question. :)