날짜 - 115년 이상 전으로 돌아가거나 5879565년 후의 미래로 갈 수 없습니다.

Question 1

시간과 날짜를 계산하는 거의 호환 가능한 방법이 많이 있습니다.

"전통적인" 유닉스 시간은 1970년("에포크"라고도 함) 이후의 초를 계산합니다. 하나 있다큰 문제32비트 표현에서는 2038년 1월 19일 화요일에 정수 오버플로가 발생합니다( ) date -d "@$((0x7fffffff))".

보다 "현대적인" 접근 방식은 64비트 카운터에서 나노초를 계산하는 것입니다.

GNU coreutils 'date'는 날짜 구문 분석을 위임합니다.DateTime2.y 구문 분석, 이는 2500줄의 들소 코드입니다. 동작은 환경에 따라 달라집니다. 예를 들어, coreutils 8.32를 사용하면 Cygwin과 Ubuntu에서 둘 다 동일한 소스에서 컴파일되었음에도 불구하고 서로 다른 동작이 발생합니다. 또한 coreutils 8.2264비트 CentOS7에서 실행 중이며 "20000000000년 전"부터 "20000000000년 전"까지의 날짜를 허용합니다.

어쨌든 - 구현에 따라 다릅니다 date.

다음을 추가하도록 편집되었습니다.

Philip Couling은 몇 가지 발견을 했습니다. 시간대를 맞추기가 어렵습니다.

또한 꼭 읽어주세요프로그래머의 시간에 대한 오해. 시간은 단순한 주제처럼 보일 수 있지만 올바른 시간을 확보하는 것은 어려울 수 있습니다.

Answer

시간과 날짜를 계산하는 거의 호환 가능한 방법이 많이 있습니다.

"전통적인" 유닉스 시간은 1970년("에포크"라고도 함) 이후의 초를 계산합니다. 하나 있다큰 문제32비트 표현에서는 2038년 1월 19일 화요일에 정수 오버플로가 발생합니다( ) date -d "@$((0x7fffffff))".

보다 "현대적인" 접근 방식은 64비트 카운터에서 나노초를 계산하는 것입니다.

GNU coreutils 'date'는 날짜 구문 분석을 위임합니다.DateTime2.y 구문 분석, 이는 2500줄의 들소 코드입니다. 동작은 환경에 따라 달라집니다. 예를 들어, coreutils 8.32를 사용하면 Cygwin과 Ubuntu에서 둘 다 동일한 소스에서 컴파일되었음에도 불구하고 서로 다른 동작이 발생합니다. 또한 coreutils 8.2264비트 CentOS7에서 실행 중이며 "20000000000년 전"부터 "20000000000년 전"까지의 날짜를 허용합니다.

어쨌든 - 구현에 따라 다릅니다 date.

다음을 추가하도록 편집되었습니다.

Philip Couling은 몇 가지 발견을 했습니다. 시간대를 맞추기가 어렵습니다.

또한 꼭 읽어주세요프로그래머의 시간에 대한 오해. 시간은 단순한 주제처럼 보일 수 있지만 올바른 시간을 확보하는 것은 어려울 수 있습니다.

Question 2

나는 여기의 최소 제한 115 years ago(1908)이 귀하의 시간대에 의한 것이라고 강하게 의심합니다. 하지만 시간대를 언급하지 않으셨기 때문에 확신할 수 없습니다.

대부분의 컴퓨터 시스템은 UTC 또는 지정된 지리적 시간대로 설정되며 일반적으로 도시를 참조합니다 Europe/London. 지리적 시간대는 정부가 장소의 시간대를 변경하고 요구할 수 있도록 허용합니다.데이터 베이스위치별 시간대~에서특정 날짜/시간. 이를 통해 날짜/시간이 일광 절약 시간제 변경 및 대부분의 정치적 어리석음에 영향을 미칠 수 있습니다.

따라서 가장 가능성이 높은 시나리오는 시간대가 1908년경의 시간대 오프셋만 기록한다는 것입니다. 반면에 UTC 계산은 시간대 데이터베이스가 UTC(및 1960년 이전의 UT[GMT])를 참조 시간으로 사용하기 때문에 무기한으로 되돌아갑니다.

시간대의 개념은 실제로 놀랍도록 새로운 것입니다.1840년. 그 이전의 시간대 계산은 지저분한 추측일 뿐이며 대륙 이동에 대한 조정이 포함될 가능성이 높습니다.

미래 5879565년의 계산은 체계적이며 Unix 시간(UTC 윤초를 고려하지 않고 1970년 1월 1일 GMT 이후의 초 수)을 기준으로 합니다.

그러나 미래의 계산을 신뢰하는 것에 대해서도 주의해야 합니다. 지금으로부터 100년 후 특정 지역의 시간대가 어떻게 될지 알 수 없습니다. 그리고 이 코드는 580만 년 동안 그리니치에 비해 엄청난 이동을 고려하지 않았습니다.

Answer

나는 여기의 최소 제한 115 years ago(1908)이 귀하의 시간대에 의한 것이라고 강하게 의심합니다. 하지만 시간대를 언급하지 않으셨기 때문에 확신할 수 없습니다.

대부분의 컴퓨터 시스템은 UTC 또는 지정된 지리적 시간대로 설정되며 일반적으로 도시를 참조합니다 Europe/London. 지리적 시간대는 정부가 장소의 시간대를 변경하고 요구할 수 있도록 허용합니다.데이터 베이스위치별 시간대~에서특정 날짜/시간. 이를 통해 날짜/시간이 일광 절약 시간제 변경 및 대부분의 정치적 어리석음에 영향을 미칠 수 있습니다.

따라서 가장 가능성이 높은 시나리오는 시간대가 1908년경의 시간대 오프셋만 기록한다는 것입니다. 반면에 UTC 계산은 시간대 데이터베이스가 UTC(및 1960년 이전의 UT[GMT])를 참조 시간으로 사용하기 때문에 무기한으로 되돌아갑니다.

시간대의 개념은 실제로 놀랍도록 새로운 것입니다.1840년. 그 이전의 시간대 계산은 지저분한 추측일 뿐이며 대륙 이동에 대한 조정이 포함될 가능성이 높습니다.

미래 5879565년의 계산은 체계적이며 Unix 시간(UTC 윤초를 고려하지 않고 1970년 1월 1일 GMT 이후의 초 수)을 기준으로 합니다.

그러나 미래의 계산을 신뢰하는 것에 대해서도 주의해야 합니다. 지금으로부터 100년 후 특정 지역의 시간대가 어떻게 될지 알 수 없습니다. 그리고 이 코드는 580만 년 동안 그리니치에 비해 엄청난 이동을 고려하지 않았습니다.

Question 3

실제로 사용 중인 구현에 따라 다릅니다.

내 버전에는 그러한 제한이 없습니다.

$ date -d "120 years ago"
Wed 12 Aug 14:20:26 UTC 1903

$ date -d "5000 years ago"
Tue 12 Aug 14:21:26 UTC -2977

(물론 날짜가 너무 이른 만큼, 사용되는 태교 달력은 좀 감안해야 합니다)

$ date -d "+9879566 years"
Sat 12 Aug 14:24:17 UTC 9881589

$ date -d "+1000000000 years"
Sat 12 Aug 14:23:39 UTC 1000002023

그것은 내가 200만년에 걸쳐 위아래로 움직일 수 있게 해준다.

$ date -d "+2147483524 years"
Tue 12 Aug 14:29:19 UTC 2147485547

$ date -d "+2147483525 years"
date: invalid date '+2147483525 years'

(124년은 2³1 = 2147483648보다 작습니다)

$ date -d "2147483772 years ago"
date: invalid date '2147483772 years ago'

$ date -d "2147483771 years ago"
Thu 12 Aug 14:32:23 UTC -2147481748

(123년은 2³1 = 2147483648보다 작습니다)

struct tm즉, 처음에 더하거나 뺄 연수를 계산할 때 a의 tm_year(1900에서 시작)의 32비트 부호 있는 값을 내부적으로 사용한다는 의미입니다.

Answer