How to get International Atomic Time in Java 7

Question

I am working on a Java7 project and we need a timestamp in International Atomic Time. I found several other questions related to this that point to JSR-310 and the ThreeTen project (which implements JSR-310):

How to get GPS time and TAI time in Java?

http://www.coderanch.com/t/549178/java/java/TAI-Atomic-Time-International

However, I am struggling to determine exactly what to use for Java 7 and where to get it. It seems like the old SourceForge and GitHub pages for ThreeTen, as well as the OpenJDK page.

I found the Java 7 reverse port, but after downloading it from Maven it does not include the TAIInstant class that I really need (the TIAInstant class is listed in the Triten SourceForge JavaDoc under javax.time. TAIInstant).

For completeness, this is an excerpt from my pom.xml:

<dependency> <groupId>org.threeten</groupId> <artifactId>threetenbp</artifactId> <version>0.8.1</version> </dependency> 

Should I use something else, and where should I get it?

Note: Sorry, I cannot provide links to all the pages that I link to, StackOverflow will not allow me to have> 2 links to a message without a higher reputation.

[EDIT] The reason for wanting TAI is that I need a timestamp that monotonously increases, and I believe that TAI performs (even during both positive and negative seconds of a jump, since it does not care about seconds of a jump, it counts all seconds equally, including seconds of jump).

After reading about POSIX / Unix time from various sources, it’s still not clear to me what happens in Unix Time in a second. I know that Unix time is ambiguous in terms of UTC time, but I don’t understand what is happening in Unix Time the moment the jump occurs? Does Unix Time use “pause” or, for example, backward? And, perhaps more importantly, even if it does not conform to the Unix Time specification, do Unix implementations really comply with the specification regarding jump seconds ...?

Finally, can I say that System.currentTimeMillis () will get the equivalent of POSIX Time (albeit in milliseconds, not seconds)?

Please note: I need an object that is transported through the JVM and machines (excluding System.nanoTime () or the like).

[Conclusion]

TAI
TAI is a time measurement system in which every second is counted, and "all seconds are equal" - i.e. every second consists of the same period of time, and all seconds (including seconds of a jump) are counted in total. This means that the number of seconds in a TAI (starting from some arbitrary starting point, such as Unix Epoch) is a monotonically increasing integer.

POSIX time
POSIX Time is a standard (NOT an implementation) for measuring time. He defines every day as exactly 86,400 seconds. Thus, POSIX time is not considered a second jump (since sometimes a minute can be 61 seconds, which leads to days s> 86,400 seconds, and theoretically a minute can be 59 seconds, which leads to days from <86400 seconds). This means that the “seconds” in POSIX are variable in length, and shortly before / during / after the jump seconds, the POSIX clock can skip seconds or repeat them. In particular, the POSIX specification referenced by Meno Hochschild in his answer states: "The relationship between the actual time of day and the current value in seconds since an era is not defined."

UTC
UTC is a time standard that is related to how the Earth moves around the Sun, striving to maintain a relationship between the position of the Sun and the time of day (within a threshold). Those. in the UTC + 0 region of the Earth, the Sun is always at its highest level at noon UTC. Seconds of a jump (positive or negative) are necessary because the Earth’s rotation speed is not fixed and it does not change in a predictable way (which means that we cannot predict when leap seconds will be needed or whether they will be positive spasmodic seconds or negative leap seconds)

Time view
It seems to me that both TAI and POSIX represent the “number of seconds” (that is, something simple for the computer to actually store), while UTC is a “human interpretation” of time (that is, Year / month / day: Minute: Second.millisecond), which is usually not stored inside the computer.

Transfer time

Given the above, there are a number of problems that translate from POSIX (without counting the seconds of a jump) to TAI (with counted stopwatch):

• This requires saving the table / number of jump seconds in order to convert any POSIX time to TAI time.
• Even if point 1 is addressed, the POSIX Spec, as mentioned above, makes no guarantees as to what will happen during the leap second, so at such times we have no way to accurately represent the unambiguous time
• If several systems must exchange data by skipping timestamps between them, we must ensure that the table / number of seconds of the jump is saved.

On the other hand, it is easy to convert human interpretation from POSIX to UTC. It does not require knowing the seconds of the jump, since it simply assumes that every day has the same number of seconds (although some of these “seconds” have different time durations in reality). In practice, you simply use the inverse formula in the POSIX Spec to get the various UTC time components (again, see the POSIX Specification referenced by Meno Hochschild).

Answer 1

JSR-310-backport only supports functions that will be included in Java 8. TAI (and true UTC) will not be a supported function, so it cannot be included in backport. The only alternative would be to try using threeten-extra-project, which contains the TAIInstant class, but the whole additional project may be out of date (very old code).

I myself am working on my Time4J library, which has TAI, GPS, and UTC support in addition to POSIX.

[ UPDATE since July 2014 : Time4J is now available as a stable version of time4j-v1.0 . This discussion has been taken into account - see, for example, Moment.toString (TimeScale) .]

---

Correction and detailed notes on new OP posts:

a) Yes, TAI monotonically increases in SI units even during leap seconds. If this is just what you want, you can choose TAI, but there is a trap. If you want to describe timestamps, then TAI will provide you with incorrect timestamps (just compare the first and second columns of the Wikipedia diagram ). The reason is that civilian life is governed by UTC, not TAI.

b) About my comments that the Wikipedia diagram is incorrect, I looked at it very carefully and changed my mind. The relationship between POSIX and TAI is not fixed (10 s offset only in 1972), so please excuse my mistake. So far I have not thought much about TAI, but about POSIX and UTC. But thanks for this question and this enlightening discussion so that you deserve my exaltation. All this is complicated. When we talk about timestamps presented at different timelines, we need to make the difference between the ymdhms form and the epochsecs form. Let's look at it in detail for the time 1999-01-01T00: 00: 00Z (UTC scale):

  i) TAI = (29 * 365 + 7) days * 86400 + 22 leap seconds + 10s (offset at 1972) = 915148832 ii) UTC = TAI - 10 = 915148822 (fixed relation between UTC and TAI on epoch-second-level) iii) POSIX = UTC - 22 leap seconds = 915148800 => (ymdhms-form); i) TAI (915148800 + 32) = 1999-01-01T00:00:32 (based on TAI-"day" = 86400 SI-secs) ii) UTC = 1999-01-01T00:00:00 (stripped off former 22 leap secs in conversion to ymdhms) iii) POSIX = 1999-01-01T00:00:00 (fixed relation between UTC and POSIX with exception of leapsecs) 

So why the statement that TAI does not count seconds of a jump? It does not account for leapsecs in the form of ymdhms, but, of course, it takes them into account at the second level level (the requirement of monotony!). And POSIX? It does not account for seconds of jump, a niter in the form of ymdhms or at the level of eras. So, we do not have a fixed connection between TAI and POSIX. A second jump table is required for conversion.

c) What will POSIX say about the spasmodic behavior of the second? See here . Especially pay attention to the expression: "The relationship between the actual time of the day and the current value in seconds since the era is not defined." So this also applies to the second jump. It depends on the implementation of the watch if they jump before the second jump or jump after or freeze for one second.

d) Yes, System.currentTimeMillis() will get the equivalent of POSIX Time (albeit in milliseconds, not seconds).

e) It should be noted that the TAI label was not defined until 1971 and International Atomic Time no earlier than 1958, so the proleic scale of the triple-extracurricular TAIInstant is somehow nonsense. Therefore, I would not apply TAI until 1972. Here I go with Steve Allen, an expert on timelines.

f) If you need a time object that is "transported through the JVM and machines", then UTC itself requires the ubiquity of the distribution / existence of the same second level table. If you choose TAI, you still need this second jump table so that applications can convert TAI timestamps to UTC- or POSIX timestamps. Therefore, I doubt that you can have a monotonously increasing time stamp and at the same time ignore leap seconds. TAI does not offer a solution to this dilemma.

Answers to the OP question / resume from 2013-12-31:

Your CVs on TAI and POSIX are correct.

About UTC, you must first understand that UTC is a compromise. On the one hand, it is designed to observe the sun, on the other hand, the second on the UTC scale is exactly the same as on the TAI scale, namely SI-second (atomic definition). You are right when you say that the speed of rotation of the earth slows down unpredictably, so the jump seconds are inserted several times. The difference between UT1 (average solar time) and UTC should always be less than 0.9 SI seconds. Thus, this and the fact of equal seconds SI are the main ideas of UTC. As an aside, the adaptation of the exotic UTC-SLS to JSR-310 is incompatible with these basic UTC ideas. Regarding the predictability of leap seconds, BIPM in Paris announces every six months if there will be a necessary leap after 6 months or not, so you have this predictability six months in advance.

Perhaps the pedantic correction in the UTC section, you wrote: "The sun is always at noon at UTC." A similar statement is also given in javadoc of the java.time.Instant class about the so-called time scale of java. Left aside the fact that you, of course, did not want to say that the position of the sun does not depend on your local position, it is not even correct at the correct longitude at noon. What for? From an astronomical / scientific point of view, you must first remember that the average time of the sun is not the same as the true local solar time that you are observing (simply by giving the keyword “equation of time”). In addition, since UTC is still based on atomic time and uses atomic time for synchronization, there is a so-called delta-T connection between UT1 and UTC. This delta is within 0.9 seconds and is regularly published by IERS / BIPM in Bulletin B. You need to know this delta when you want to get the real position of the sun and when the sun will be highest.

The "Presentation of Time" section, in my opinion, is too simple. Well, we can say that TAI and POSIX count seconds, while UTC is more likely represented in the form year / month / day /...-. But we can really apply both concepts on all scales. But we need to carefully distinguish between these ideas and think carefully about how to convert. Note that Wikipedia even chose the ymdhms form for TAI in the charts. Well, computers can best store prime integers. And POSIX or TAI can easily be saved in this format. But, as I said, the interpretation of these integers is not always simple. In the case of TAI, you even need a second leap table to convert to a readable ymdhms form in Civil format (UTC or POSIX).

About the next section, "Time Transfer," I agree with paragraphs 1-3.

Your last statement: “On the other hand, it is easy to convert“ human interpretation ”from POSIX to UTC. It’s correct, except for seconds of jump. Well, I give a suitable translation between different scales with my future library. It has a built-in, but customizable table of the second level, and in the future I also plan to use IANA-TZDB data as a source for such a table.

Everyone knows that most business developers do not need such accuracy. Most people simply align POSIX and UTC and are likely to be satisfied with any smoothing hardware solutions on Linux or Google’s NTP servers. True UTC and TAI (that is, given the seconds of the jump) require more effort. Therefore, you need to decide whether your software architecture is needed for scientific accuracy.

And just to point out, JSR-310 does not officially refer to very large-scale POSIX in general, instead they say that their Instant class should be UTC-SLS by definition (see also this interesting discussion ).

Finally, I am elegant for this discussion. It also helped me clarify my thoughts on TAI in my library. Thanks.

Answer 2

The TAIInstant class, and others, such as UTCInstant , were removed during the JSR-310 process. The group concluded that these are specialized items and do not have to be in the main JDK. I still think this is the right decision.

The result of this is that there is very little time-scale support in JSR-310. However, there is a formally defined way to connect the JSR-310 to a time scale, allowing you to create accurate watches with an accurate source. Although not everyone likes this solution, it is practical for the mainstream.

Thus, the original design of the individual classes for UTC and TAI sounds (and is necessary for handling events in the past and in the future). However, he was too specialist for the JDK.

The threeten-extra project is now available as a jar for JDK 8 with these classes in.