Java 7에서 국제 원자 시간을 얻는 방법

Question

저는 Java7 프로젝트에서 작업 중이며 국제 원자 시간 (International Atomic Time)에 타임 스탬프가 필요합니다. 그러나

How to get GPS Time and TAI time in Java?

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

, I가 사투를 벌인거야 : 나는이에 (JSR-310 구현됩니다) JSR-310 및 ThreeTen 프로젝트를 가리키는 관련된 몇 가지 다른 문제를 발견했습니다 Java 7에 대해 사용할 대상과 그 위치를 정확히 찾아야합니다. ThreeTen을위한 GitHub 페이지뿐만 아니라 OpenJDK 페이지도 올드 라이프 소스 & 인 것으로 보입니다.

Java 7 백 포트를 찾았지만 Maven에서 다운로드 한 후에 실제로 필요한 TAIInstant 클래스가 포함되어 있지 않습니다. TIAInstant 클래스는 javax.time의 ThreeTen SourceForge JavaDoc에 나열되어 있습니다. .TAIInstant). 완성도를 들어

이 내 pom.xml 파일에서 발췌 한 것입니다

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

내가 뭔가를 사용하는 경우, 그리고 어디에서 점점되어야 하는가?

참고 : 죄송합니다. 내가 언급 한 모든 페이지에 대한 링크를 제공 할 수 없으므로 StackOverflow에서 상위 담당자없이 게시물 당 2 링크 이상을 허용하지 않습니다.

[EDIT] TAI를 원하는 이유가 도약 걱정하지 않기 때문에, I는 I가 TAI에도 긍정적 & 제외 윤초 둘 중 (성취 판단 단조 증가하는 타임 스탬프를 필요로한다는 것이다 초 은 윤초를 포함하여 모든 초를 똑같이 계산합니다.

다양한 소스에서 POSIX/Unix 시간을 읽은 후에도 유닉스 시간에서 윤초가 어떻게 발생하는지 정확하게 알 수 없습니다. 나는 유닉스 시간이 UTC 시간을 언급하는 측면에서 모호하다는 것을 안다. 그러나 나는 유닉스 시간에서 도약이 일어난 순간에 어떤 일이 일어나는지 분명하지 않다. 유닉스 시간이 예를 들어 '일시 중지'또는 뒤로 이동합니까? 그리고 아마도 더 중요한 것은 유닉스 타임 스펙에 따르면 안된다고해도, 유닉스 구현은 실제로 윤초에 관한 스펙을 따르는 것인가 ...?

마지막으로, System.currentTimeMillis()가 POSIX Time (초 단위가 아니라 밀리 초)과 동일하다는 점을 수정 했습니까?

참고, JVM 및 컴퓨터간에 이식 가능한 객체가 필요합니다 (System.nanoTime() 또는 유사한 예외가 있음).

TAI
TAI 매초 '가 모두 동일 초'카운트된다 시간을 측정하는 시스템이다 [결론] - 즉. 매초마다 같은 기간으로 구성되며 모든 초 (윤초 포함)는 총계로 계산됩니다. 즉, TAI의 임의의 시작 시점에서 계산 된 초 수 (예 : Unix Epoch)는 단조롭게 증가하는 정수입니다.

POSIX 시간
POSIX 시간 시간을 측정하기위한 표준 (NOT 구현)입니다. 매일 86400 초를 정확하게 기록합니다.따라서 POSIX 시간은 윤초를 계산하지 않습니다. (경우에 따라 1 분이 61 초를 초과하여> 86400 초가되며 이론적으로 1 분이 59 초이므로 < 86400 초가됩니다). 즉, POSIX의 'seconds'는 가변 길이를 가지며 윤초 전/도중/후에 POSIX 시계는 초를 건너 뛰거나 반복 할 수 있습니다. 특히 Meno Hochschild가 참조한 POSIX 사양은 "실제 시간과 Epoch 이후의 초에 대한 현재 값 사이의 관계는 지정되지 않았습니다."라고 대답했습니다.

UTC
UTC는 태양의 위치와 (임계 값에서) 하루의 시간과의 관계를 유지하는 것을 목표로, 지구가 태양 주위를 이동하는 방법과 관련된 시간 표준입니다. 즉, 지구의 UTC + 0 지역에서 태양은 항상 정오 UTC 시간대에 가장 높습니다. 지구의 회전 속도가 고정되어 있지 않고 예상 할 수있는 방식으로 변화하지 않기 때문에 閏초 (양수 또는 음수)가 필요합니다. 즉, 윤초가 필요할 때를 예측할 수 없거나 양성 윤일인지 또는

시대를 대표하는 음의 윤초)
는 TAI와 POSIX 모두 '초 카운트'의 표현이라는 것을 날 것으로 보인다 (예. 실제로 저장소에 컴퓨터에 대한 쉬운 일), UTC는 '인간 반면 해석 (interpretation) '(즉, 년/월/일 시간 : 분 : 초. 밀리 세컨드).

번역 타임즈
을 감안할 때, POSIX에서 번역 문제의 숫자가 TAI에 (윤초는 계산으로) (계산 어떤 윤초없이) 위 : 그것은 테이블을 유지 필요

1. /POSIX 시간을 TAI 시간으로 변환 할 수있는 윤초의 수
2. 포인트 1이 처리 되더라도, 위와 같은 POSIX 스펙은 도중 중 윤초가 발생할 수 있음을 보증하지 않으므로, 정확하게 표현하는 방법 시스템의 숫자가 통신해야하는 경우 명확한 시간
3. 을 nting하는 것은, 그들 사이에 타임 스탬프를 통과, 우리는 윤초의 테이블/수가 한편

일관성을 유지하도록 보장해야한다, 변환하기 쉬운 POSIX에서 UTC '인간의 해석'까지 윤일 초에 대한 지식이 필요하지 않습니다. 왜냐하면 매일 매일 같은 초 수를 사용한다고 가정하기 때문입니다. (실제로이 초의 일부는 실제 시간 길이가 다릅니다.) 실제로는 POSIX Spec의 수식의 역함수를 사용하여 여러 가지 UTC 구성 요소를 얻을 수 있습니다 (다시 Meno Hochschild가 참조한 POSIX 사양 참조).

Answer 1

JSR-310-backport는 Java 8에 포함될 기능 만 지원합니다. TAI (및 true UTC)는 지원되는 기능이 아니므로 백 포트에있을 수 없습니다. 유일한 대안은 TAIInstant 클래스가 포함 된 threeten-extra-project를 시도하는 것이지만, 전체 프로젝트가 최신이 아닐 수도 있습니다 (아주 오래된 코드).

필자는 자신의 라이브러리 인 Time4J에 POSIX 외에도 TAI, GPS 및 UTC를 지원하고 있습니다.

[업데이트 날짜 : 2014 년 7 월 20 일 : Time4J는 이제 안정 버전 time4j-v1.0으로 사용할 수 있습니다. 이 논쟁은 고려되었습니다. 예를 들어 Moment.toString(TimeScale) 을보십시오.] OP의 새로 게시 된 질문에

---

보정 및 세부 발언 :

A) 네, TAI는 단조도 윤초시 SI-초 단위로 증가하고있다. 그것이 단지 당신이 원하는 것이면 TAI를 선택할 수도 있지만 함정이 있습니다. 시민의 시간 소인을 설명하려면 TAI가 잘못된 시간 소인을 제공합니다 (Wikipedia diagram의 첫 번째와 두 번째 열을 비교하면됩니다). 그 이유는 시민 생활이 TAI가 아닌 UTC에 의해 통치된다는 것입니다.

b) Wikipedia 다이어그램이 잘못되었다는 의견에 대해 다시 살펴보고 마음이 바뀌 었습니다. POSIX와 TAI의 관계는 고정되어 있지 않으므로 (1972 년에만 10 초 오프셋), 제 실수를 용서하십시오. 지금까지 나는 TAI에 대해서, POSIX와 UTC에 대해서는별로 생각하지 않았습니다. 그러나 질문과이 계몽적인 토론에 감사드립니다. 그래서 당신은 나의 업보트를받을 자격이 있습니다. 모든 일은 까다 롭습니다. 서로 다른 시간 척도로 표현 된 타임 스탬프에 관해 이야기 할 때 우리는 ymdhms 형식과 epochsec 형식의 차이를 만들어야합니다. 이제 시간이 1999-01-01T00에 대해 자세하게 살펴 보겠습니다 : 00 : 00Z (UTC 규모) :

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) 

왜 TAI는 윤초를 계산하지 않는 문? ymdhms 형식의 leapsecs는 계산하지 않지만, 물론 epoch-second-level (단조 로움 요구 사항!)에서 계산합니다. 그리고 POSIX? 윤초를 일절 계산하지 않고, ymdhms 형식이나 epoch-secs 수준을 신경 쓰지 않습니다. 결국 우리는 TAI와 POSIX간에 고정 된 관계가 없습니다. 변환을 위해 윤년 두 번째 테이블이 필요합니다.

c) POSIX 사양에서 윤초 두 번째 동작을 알리는 것은 무엇입니까? here을 참조하십시오. 특히 다음과 같은 진술을 주목하십시오 : "실제 시간과 에포크 이후의 초에 대한 현재 값 사이의 관계는 불특정". 그래서 이것은 두 번째 도약과 관련이 있습니다. 두 번째 도약 전에 점프하거나 1 초 동안 멈추거나 멈 추면 구현을 구현하는 것이 좋습니다.

d) 예, System.currentTimeMillis()은 POSIX 시간 (초 단위가 아니라 밀리 초)과 같습니다.

e) TAI 레이블은 1971 년 이전에 정의되지 않았으며 국제 원자 시간은 1958 년 이전에 정의되지 않았으므로 threeten-extra-class TAIInstant의 프롤레틱 스케일은 어쩐지 난센스입니다. 그래서 나는 1972 년 이전에 TAI를 적용하지 않을 것입니다. 여기서는 시간 척도의 전문가 인 Steve Allen과 함께합니다.

f) "JVM 및 머신에서 이식 가능한"시간 객체가 필요하다면 UTC 자체에서 모든 도약 테이블에 동일한 윤년 테이블이 존재해야합니다. TAI를 선택하면 응용 프로그램이 TAI 시간 소인을 UTC 또는 POSIX 시간 소인으로 변환 할 수 있도록이 윤년 제 2 테이블이 필요합니다. 그래서 나는 당신이 단조롭게 증가하는 타임 스탬프를 가질 수 있고 동시에 윤초를 무시할 수 있다고 생각하지 않습니다. TAI는 이러한 딜레마에 대한 해결책을 제공하지 않습니다.

답변 2013년 12월 31일에서/OP의 요약 질문 : TAI와 POSIX에 대한

귀하의 요약이 정확합니다.

UTC에 대해 UTC가 타협임을 이해해야합니다. 한쪽은 태양을 따르도록 설계되었고, 다른 한면에는 UTC 눈금의 두 번째 눈금이 TAI 눈금의 SI-second (원자 정의)와 정확히 동일합니다. 지구 회전 속도가 예기치 않게 느려지라고 말했을 때 당신 말이 맞습니다. 그래서 몇 초간 윤년이 삽입됩니다. UT1 (평균 태양 시간)과 UTC 사이의 차이는 항상 0.9 SI 초보다 작아야합니다.따라서 이것이 SI 초와 동일한 사실은 UTC의 핵심 아이디어입니다. JSR-310에서 이국적인 UTC-SLS 스케일을 적용하는 것은 UTC의 핵심 아이디어와 호환되지 않습니다. 윤년의 예측 가능성에 대해 파리의 BIPM은 6 개월 후에 윤년 초가 필요하거나 없을 경우 매 반년을 발표하므로 사전 예측 가능성이 6 개월입니다.

어쩌면 UTC 섹션에 대한 현학적 인 수정 일 가능성이 있습니다. "태양은 항상 UTC 시간대의 가장 높은 곳에 있습니다." 비슷한 문장이, 소위 java 시간 스케일에 관한 java.time.Instant 클래스의 javadoc에서도 제공됩니다. 태양의 위치가 당신의 지역 위치와 독립적이라고 말할 필요가 없다는 사실을 제쳐 놓고 말하면, 정오의 적당한 경도에서도 정확하지 않습니다. 왜? 천문학적/과학적 관점에서 태양의 평균 태양 시간은 실제 태양의 태양 시간과 같지 않다는 것을 잊지 말아야합니다 (단지 "시간 방정식"이라는 키워드를 사용). 또한 UTC는 여전히 원자 시간을 기반으로하고 동기화에 원자 시간을 사용하기 때문에 UT1과 UTC 사이에 델타 -T- 관계가 있습니다. 이 델타는 0.9 초의 프레임 내에 있으며 게시판 B의 IERS/BIPM에 의해 정기적으로 게시됩니다. 태양의 실제 위치를 얻고 싶을 때와 태양이 가장 높을 때이 델타를 알아야합니다.

"시간 표현하기"섹션은 제 의견으로는 너무 간단합니다. TAI와 POSIX는 초를 계산하지만 UTC는 년/월/일 /...- 형태로 표현하는 것이 좋습니다. 그러나 우리는 실제로 두 가지 표현을 모든 가늠자에 적용 할 수 있습니다. 그러나 우리는 이러한 표현을 신중하게 구별하고 변환 방법을 철저히 생각해야합니다. Wikipedia는 다이어그램에서 TAI에 대한 ymdhms-form을 선택했습니다. 음, 컴퓨터는 단순한 정수를 저장하는 것이 가장 좋습니다. 그리고 POSIX 또는 TAI는 그 형식으로 쉽게 저장 될 수 있습니다. 그러나 전에 말했듯이이 정수의 해석은 항상 단순하지는 않습니다. TAI의 경우에는 읽을 수있는 시민 ymdhms 형식 (UTC 또는 POSIX 중 하나)으로 변환하기 위해 두 번째 테이블 도약이 필요합니다.

다음 번 "번역 시간"부분에 대해서는 1-3 점에 동의합니다.

"다른 한편으로 POSIX에서 UTC '인간의 해석'으로 쉽게 변환 할 수 있습니다." 윤초를 제외하고는 맞습니다. 글쎄, 나는 다가올 도서관에서 다른 저울들 사이의 적절한 번역을 가능하게한다. 그것은 내장되어 있지만 구성 가능한 윤년 테이블을 가지고 있으며, 앞으로 IANA-TZDB 데이터를 그러한 테이블의 소스로 사용할 계획입니다.

대부분의 비즈니스 개발자는 정확성이별로 필요하지 않습니다. 대부분의 사람들은 단순히 POSIX와 UTC를 동일하게 만들 것이며 Linux OS 또는 Google NTP 서버의 모든 하드웨어 스무딩에 만족할 것입니다. 진정한 UTC와 TAI (즉, 윤초를 감안)에는 더 많은 노력이 필요합니다. 따라서 소프트웨어 아키텍처에 과학적 정확성이 필요한지 여부를 결정해야합니다.

JSR-310은 공식적으로 매우 광범위하게 확장 된 POSIX를 공식적으로 다루지 않지만, Instant라는 클래스는 UTC-SLS로 정의됩니다 (이 또한 흥미로운 debate 참조).

마지막으로 나는이 토론에 대해 우아합니다. 또한 제 도서관의 TAI에 대한 제 생각을 분명히하는 데 도움이되었습니다. 감사.

Answer 2

클래스 TAIInstant 및 기타 UTCInstant은 JSR-310 프로세스 중에 제거되었습니다. 그룹은 이것들이 전문적인 항목이고 핵심 JDK에있을 필요는 없다는 결론에 도달했습니다. 나는 아직도 이것이 올바른 결정이라고 믿는다.

결과는 JSR-310에서 시간 스케일에 대한 지원이 거의 없다는 것입니다. 그러나 JSR-310을 시간 스케일에 연결하는 정식 정의 된 방법이 있으므로 정확한 소스가 주어지면 정확한 시계를 만들 수 있습니다. 모든 사람들이이 솔루션을 좋아하지는 않지만, 주류는 실용적입니다.

요약하면 UTC와 TAI에 대한 별도의 클래스 디자인은 건전하고 (과거와 미래의 이벤트를 처리하는 데 필요함) 요약하자면 다음과 같습니다. 그러나 JDK는 너무 전문적이었습니다.

threeten-extra 프로젝트에서와 these classes JDK 8 병으로서 사용할 수있다.