날짜 (1970 년 1 월 1 일)를 기본 표준으로 사용

질문은 두 가지 잘못된 가정을합니다.

• 컴퓨팅의 모든 시간 추적은 1970 년 이후로 수행됩니다.
• 이러한 추적은 표준입니다.

이십 에포크

계산 시간 이 1970 UTC 초부터 항상 추적되는 것은 아닙니다 . 이 epoch 참조 가 인기가 있지만 수십 년 동안 다양한 컴퓨팅 환경에서 거의 24 epoch를 사용했습니다 . 일부는 다른 세기에서 왔습니다. 0 년부터 2001 년까지의 범위입니다.

다음은 몇 가지입니다.

기원전 1 년 1 월 0 일

AD 1 년 1 월 1 일

1582 년 10 월 15 일

1601 년 1 월 1 일

1840 년 12 월 31 일

1858 년 11 월 17 일

1899 년 12 월 30 일

1899 년 12 월 31 일

1900 년 1 월 1 일

1904 년 1 월 1 일

1967 년 12 월 31 일

1980 년 1 월 1 일

1980 년 1 월 6 일

2000 년 1 월 1 일

2001 년 1 월 1 일

Unix Epoch 공통이지만 지배적이지는 않음

1970 년 초는 유닉스에서 사용 되었기 때문에 인기가 있습니다. 그러나 결코 그렇게 우세한 것은 아닙니다. 예를 들면 :

• 수백만 (십억?)의 Microsoft Excel 및 Lotus 1-2-3 문서가 사용됩니다 January 0, 1900(1899 년 12 월 31 일).
• 세계는 지금 가지고 억 이상 아이폰 OS / OS X 장치 사용 코코아 (있는 NSDate) 시대 의를 1 January 2001, GMT.
• GPS의 위성 항법 시스템을 사용하는 January 6, 1980유럽의 대안 동안 갈릴레오 사용 22 August 1999.

ISO 8601

count-since-epoch가 Unix epoch를 사용한다고 가정하면 버그에 대한 큰 취약성이 열립니다. 이러한 카운트는 사람이 즉시 해독 할 수 없으므로 디버깅 및 로깅시 오류 또는 문제가 쉽게 표시되지 않습니다. 또 다른 문제는 아래에 설명 된 세분성의 모호성입니다.

명확한으로 난 강력하게 대신 직렬화 날짜 – 시간 값을 제안 ISO 8601 : 데이터 문자열이 정수 카운트 이후-시대보다는 교환 YYYY-MM-DDTHH:MM:SS.SSSZ등 2014-10-14T16:32:41.018Z.

백작 무엇 신기원 때문에

에포크 이후 카운트 시간 추적의 또 다른 문제는 일반적으로 사용되는 최소 4 단계의 해상도를 사용하는 시간 단위입니다.

• 초
  원래의 Unix 기능은 전체 초를 사용 하여 32 비트 정수로 저장하면 1970 년 이후 초 제한에 도달하면 2038 년 문제로 이어 졌습니다.
• 밀리 초
  번들 java.util.Date 클래스 및 Joda-Time 라이브러리를 포함하여 이전 Java 라이브러리에서 사용됩니다 .
• 마이크로 초 Postgres
  와 같은 데이터베이스에서 사용됩니다 .
• Java 8
  의 새로운 java.time 패키지 에서 사용되는 나노초