유닉스 시간 (역시 에포크 시간, 파직스 시간, 에포크 이후 초, 또는 유닉스 에포크 시간이라고도 함)은 특정 시점을 설명하는 시스템입니다. 그것은 유닉스 에포크 이후 경과한 초 빼기 윤초의 숫자입니다; 유닉스 에포크는 1970년 1월 1일 (임의의 날짜) 00:00:00 UTC입니다; 윤초는 그것 이전 초와 같은 유닉스 시간을 갖는 비선형이고, 매일 정확히 86400초를 포함하는 것처럼 처리됩니다. 이 처리로 인해, 유닉스 시간은 UTC의 참 표현이 아닙니다.
유닉스 시간은 운영 시스템과 파일 형식에서 널리 사용됩니다. 유닉스-계열 운영 시스템에서, date는 현재 시간을 인쇄 또는 설정하는 명령입니다; 기본적으로, 그것은 시스템 시간대에서 시간을 인쇄 또는 설정하지만, -u 플래그와 함께, 그것은 시간을 UTC로 인쇄 또는 설정하고, 특정 시간대를 참조하도록 설정된 TZ 환경 변수와 함께, 해당 시간대에서 시간을 인쇄 또는 설정합니다.
Definition
두 개의 인코딩 레이어가 유닉스 시간을 구성합니다. 첫 번째 계층은 1970년 1월 1일 목요일 00:00:00 UTC 이후 경과된 초의 숫자를 나타내는 스칼라 실수로 시점을 인코딩합니다. 두 번째 계층은 해당 숫자를 일련의 비트 또는 십진 자릿수로 인코딩합니다.
UTC의 표준과 마찬가지로, 이 기사는 그레고리력을 사용하여 날짜에 레이블을 지정하고, 각 날짜의 시간을 시, 분, 및 초 단위로 계산합니다. 일부 예제는 역시 같은 초를 사용하고 UTC와 같은 형식으로 표시되는 또 다른 시간 체계, International Atomic Time (TAI)를 보여주지만, 그것에서 매일은 정확히 86400초이며, 매년 대략 1초의 비율로 지구의 자전과 점차적으로 동기화를 잃습니다.
Encoding time as a number
유닉스 시간은 매초마다 증가하는 단일 부호화된 숫자로, 전통적인 날짜 시스템보다 컴퓨터에 대해 더 쉽게 저장되고 조작됩니다. 해석기 프로그램이 그런-다음 그것을 사람이 읽을 수 있는 형식으로 변환할 수 있습니다.
유닉스 에포크는 1970년 1월 1일 00:00:00 UTC 시간입니다. UTC가 1972년까지 현재 형식으로 존재하지 않았다는 점에서 이 정의에는 문제가 있습니다; 이 문제는 아래에서 논의됩니다. 간결함을 위해, 이 섹션의 나머지 부분에서는 ISO 8601 날짜 및 시간 형식을 사용하며, 이것에서 유닉스 에포크는 1970-01-01T00:00:00Z입니다.
유닉스 시간 숫자는 유닉스 에포크에서 0이고, 에포크 이후로 정확히 하루에 86400씩 증가합니다. 따라서 2004-09-16T00:00:00Z, 에포크 후 12677 날짜는 유닉스 시간 숫자 12677 × 86400 = 1095292800으로 표시됩니다. 이것은 음수를 사용하여 에포크에서 뒤방향으로 확장할 수도 있습니다; 따라서 1957-10-04T00:00:00Z, 에포크 전 4472 날짜는 유닉스 시간 숫자 −4472 × 86400 = −386380800으로 표시됩니다. 이것은 마찬가지로 며칠 내에도 적용됩니다; 하루 중 임의의 주어진 시간에서 시간 숫자는 해당 자정의 시간 숫자에 더해진 해당 날짜를 시작하는 자정 이후 경과한 초의 숫자입니다.
유닉스 시간은 에포크를 기반으로 하고, 유닉스 에포크가 유일한 에포크 (종종 "The Epoch"라고 함)라는 공통적인 오해로 인해 유닉스 시간은 때때로 에포크 시간이라고 잘못 언급하는 경우가 있습니다.
Leap seconds
위의 방식은 86400 초의 지속 시간을 가지는 정규 UTC 날짜에, 유닉스 시간 숫자가 자정에 걸쳐 연속적 방식으로 변경됨을 의미합니다. 예를 들어, 위의 예제에서 사용된 하루가 끝나면 시간 표현은 다음과 같이 진행됩니다:
| Unix time across midnight into 17 September 2004 (no leap second) | ||
| TAI (17 September 2004) | UTC (16 to 17 September 2004) | Unix time |
| 2004-09-17T00:00:30.75 | 2004-09-16T23:59:58.75 | 1 095 379 198.75 |
| 2004-09-17T00:00:31.00 | 2004-09-16T23:59:59.00 | 1 095 379 199.00 |
| 2004-09-17T00:00:31.25 | 2004-09-16T23:59:59.25 | 1 095 379 199.25 |
| 2004-09-17T00:00:31.50 | 2004-09-16T23:59:59.50 | 1 095 379 199.50 |
| 2004-09-17T00:00:31.75 | 2004-09-16T23:59:59.75 | 1 095 379 199.75 |
| 2004-09-17T00:00:32.00 | 2004-09-17T00:00:00.00 | 1 095 379 200.00 |
| 2004-09-17T00:00:32.25 | 2004-09-17T00:00:00.25 | 1 095 379 200.25 |
| 2004-09-17T00:00:32.50 | 2004-09-17T00:00:00.50 | 1 095 379 200.50 |
| 2004-09-17T00:00:32.75 | 2004-09-17T00:00:00.75 | 1 095 379 200.75 |
| 2004-09-17T00:00:33.00 | 2004-09-17T00:00:01.00 | 1 095 379 201.00 |
| 2004-09-17T00:00:33.25 | 2004-09-17T00:00:01.25 | 1 095 379 201.25 |
윤초가 발생할 때, UTC 날짜는 정확히 86400는 아니고 유닉스 시간 숫자 (항상 매일 정확하게 86400씩 증가)는 불연속성을 경험합니다. 윤초는 양수 또는 음수일 수 있습니다. 음의 윤초는 선언된 적이 없지만, 선언되면, 음의 윤초를 갖는 하루의 끝에서, 유닉스 시간 숫자는 다음 날 시작으로 1만큼 증가합니다. 평균적으로 약 1년 반 정도 발생하는 하루의 끝에서 양의 윤초 동안, 유닉스 시간 숫자는 윤초 동안 다음 날까지 계속 증가하고 그런-다음 윤초의 끝에서 1만큼 뒤로 점프합니다 (다음 날 시작으로 돌아갑니다). 예를 들어, 이것은 1998년 말에 POSIX.1 시스템을 엄격히 준수하여 발생하는 것입니다:
| Unix time across midnight into 1 January 1999 (positive leap second) | ||
| TAI (1 January 1999) | UTC (31 December 1998 to 1 January 1999) | Unix time |
| 1999-01-01T00:00:29.75 | 1998-12-31T23:59:58.75 | 915 148 798.75 |
| 1999-01-01T00:00:30.00 | 1998-12-31T23:59:59.00 | 915 148 799.00 |
| 1999-01-01T00:00:30.25 | 1998-12-31T23:59:59.25 | 915 148 799.25 |
| 1999-01-01T00:00:30.50 | 1998-12-31T23:59:59.50 | 915 148 799.50 |
| 1999-01-01T00:00:30.75 | 1998-12-31T23:59:59.75 | 915 148 799.75 |
| 1999-01-01T00:00:31.00 | 1998-12-31T23:59:60.00 | 915 148 800.00 |
| 1999-01-01T00:00:31.25 | 1998-12-31T23:59:60.25 | 915 148 800.25 |
| 1999-01-01T00:00:31.50 | 1998-12-31T23:59:60.50 | 915 148 800.50 |
| 1999-01-01T00:00:31.75 | 1998-12-31T23:59:60.75 | 915 148 800.75 |
| 1999-01-01T00:00:32.00 | 1999-01-01T00:00:00.00 | 915 148 800.00 |
| 1999-01-01T00:00:32.25 | 1999-01-01T00:00:00.25 | 915 148 800.25 |
| 1999-01-01T00:00:32.50 | 1999-01-01T00:00:00.50 | 915 148 800.50 |
| 1999-01-01T00:00:32.75 | 1999-01-01T00:00:00.75 | 915 148 800.75 |
| 1999-01-01T00:00:33.00 | 1999-01-01T00:00:01.00 | 915 148 801.00 |
| 1999-01-01T00:00:33.25 | 1999-01-01T00:00:01.25 | 915 148 801.25 |
유닉스 시간 숫자는 양의 윤초 바로 다음에 오는 초에서 반복됩니다. 유닉스 시간 숫자 1483142400은 따라서 모호합니다: 그것은 윤초의 시작 (2016-12-31 23:59:60) 또는 그것의 끝, 1초 후 (2017-01-01 00:00: 00)를 참조할 수 있습니다. 음의 윤초가 발생하는 이론적인 경우에서, 모호성이 발생하지 않지만, 대신에 UTC 시간의 어떤 지점도 전혀 참조하지 않는 유닉스 시간 숫자 범위가 있습니다.
유닉스 시계는 종종 네트워크 시간 프로토콜 (NTP)과 관련된 다른 유형의 양의 윤초 처리로 구현됩니다. 이것은 POSIX 표준을 준수하지 않는 시스템을 생성합니다. 자세한 내용에 대해 NTP에 관한 아래 섹션을 참조하십시오.
UTC 윤초를 포함하지 않는 기간을 처리할 때, 두 유닉스 시간 숫자 사이의 차이는 시간에서 해당 지점 사이의 기간의 초에서 지속기간과 같습니다. 이것은 일반적인 계산 기술입니다. 어쨌든, 윤초가 발생하는 곳에서, 그러한 계산은 잘못된 답을 제공합니다. 이러한 수준의 정확도가 요구되는 응용 프로그램에서, 유닉스 시간을 처리할 때 윤초 테이블을 참조할 필요가 있고, 종종 이 문제를 겪지 않는 다른 시간 인코딩을 사용하는 것이 더 선호됩니다.
유닉스 시간 숫자는 유닉스 시간 숫자, 모듈로 86400의 몫과 모듈러스를 취함으로써 UTC 시간으로 쉽게 다시 변환됩니다. 그 몫은 에포크 이후의 일 수이고 모듈러스는 해당 날에서 UTC 자정 이후의 초 수입니다. 만약 양의 윤초로 인해 모호한 유닉스 시간 숫자가 주어지면, 이 알고리듬은 이를 자정 직후의 시간으로 해석합니다. 그것은 윤초 동안의 시간은 생성하지 않습니다. 만약 음의 윤초로 인해 유효하지 않은 유닉스 시간 숫자가 주어지면, 마찬가지로 유효하지 않은 UTC 시간을 생성합니다. 만약 이들 조건이 중요하면, 그것을 감지하기 위해 윤초 테이블을 참조해야 합니다.
Non-synchronous Network Time Protocol-based variant
공통적으로 Mills-스타일 유닉스 시계는 유닉스 시간 숫자의 변경과 동기화되지 않은 윤초 처리로 구현됩니다. 처음에는 도약이 일어나야 할 곳에서 시간이 감소하고, 도약 후 1초 후에 정확한 시간으로 도약합니다. 이것은 구현을 더 쉽게 만들고 Mills의 논문에 설명되어 있습니다. 이것은 양의 윤초에서 발생하는 일입니다:
| Non-synchronous Mills-style Unix clocka cross midnight into 1 January 1999 (positive leap second) |
|||
| TAI (1 January 1999) | UTC (31 December 1998 to 1 January 1999) | State | Unix clock |
| 1999-01-01T00:00:29.75 | 1998-12-31T23:59:58.75 | TIME_INS | 915 148 798.75 |
| 1999-01-01T00:00:30.00 | 1998-12-31T23:59:59.00 | TIME_INS | 915 148 799.00 |
| 1999-01-01T00:00:30.25 | 1998-12-31T23:59:59.25 | TIME_INS | 915 148 799.25 |
| 1999-01-01T00:00:30.50 | 1998-12-31T23:59:59.50 | TIME_INS | 915 148 799.50 |
| 1999-01-01T00:00:30.75 | 1998-12-31T23:59:59.75 | TIME_INS | 915 148 799.75 |
| 1999-01-01T00:00:31.00 | 1998-12-31T23:59:60.00 | TIME_INS | 915 148 800.00 |
| 1999-01-01T00:00:31.25 | 1998-12-31T23:59:60.25 | TIME_OOP | 915 148 799.25 |
| 1999-01-01T00:00:31.50 | 1998-12-31T23:59:60.50 | TIME_OOP | 915 148 799.50 |
| 1999-01-01T00:00:31.75 | 1998-12-31T23:59:60.75 | TIME_OOP | 915 148 799.75 |
| 1999-01-01T00:00:32.00 | 1999-01-01T00:00:00.00 | TIME_OOP | 915 148 800.00 |
| 1999-01-01T00:00:32.25 | 1999-01-01T00:00:00.25 | TIME_WAIT | 915 148 800.25 |
| 1999-01-01T00:00:32.50 | 1999-01-01T00:00:00.50 | TIME_WAIT | 915 148 800.50 |
| 1999-01-01T00:00:32.75 | 1999-01-01T00:00:00.75 | TIME_WAIT | 915 148 800.75 |
| 1999-01-01T00:00:33.00 | 1999-01-01T00:00:01.00 | TIME_WAIT | 915 148 801.00 |
| 1999-01-01T00:00:33.25 | 1999-01-01T00:00:01.25 | TIME_WAIT | 915 148 801.25 |
이것은 윤초가 아직 수행되었는지 여부를 명확하게 나타내는 윤초 상태 변수에 주의를 기울이면 적절하게 디코딩될 수 있습니다. 그 상태 변수 변경은 도약과 동기화됩니다.
유사한 상황이 음의 윤초에서 발생하며, 여기서 건너뛴 초는 약간 늦습니다. 아주 간단히 시스템은 명목상 불가능한 시간 숫자를 표시하지만, 이것은 TIME_DEL 상태에 의해 감지되고 수정될 수 있습니다.
이러한 유형의 시스템에서, 유닉스 시간 숫자는 두 유형의 윤초에 대해 POSIX를 위반합니다. 윤초 상태 변수를 시간 숫자와 함께 수집하면 명확한 디코딩이 가능하므로, 원한다면 올바른 POSIX 시간 숫자를 생성하거나 전체 UTC 시간을 보다 적합한 형식으로 저장할 수 있습니다.
이러한 유닉스 클럭 스타일에 대처하는 데 필요한 디코딩 논리는 같은 인터페이스를 사용하여 가상의 POSIX 준수 클럭도 올바르게 디코딩합니다. 이것은 삽입된 전체 윤초 동안 TIME_INS 상태를 표시하고, 그런-다음 초 카운트를 반복하면서 다음 초 전체 동안 TIME_WAIT를 표시함으로써 달성됩니다. 이것은 동기식 윤초 처리를 요구합니다. 이것은 기본 시계가 윤초에 의해 근본적으로 문제가 없을 때 유닉스 인터페이스를 통해 유닉스 시계 형식으로 UTC 시간을 표현하는 가장 좋은 방법일 것입니다.
TAI-based variant
훨씬 드물고 준수하지 않는 유닉스 시간 유지 변형에는 UTC가 아닌 TAI 인코딩이 포함됩니다; 일부 리눅스 시스템은 이러한 방식으로 구성됩니다. TAI에는 윤초가 없고 모든 TAI 하루는 정확히 86400초이므로, 이 인코딩은 실제로 1970-01-01T00:00:10 TAI 이후 경과된 초의 순수한 선형 계수입니다. 이것은 시간 간격 산술을 훨씬 더 쉽게 만듭니다. 이러한 시스템의 시간 값은 엄격하게 준수하는 POSIX 시스템 또는 NTP-구동 시스템이 가지고 있는 모호성을 겪지 않습니다.
이들 시스템에서 UTC와 유사-유닉스-시간 표현 사이를 올바르게 변환하려면 윤초 테이블을 참조해야 합니다. 이것은 표준시로 변환하기 위해 표준 시간대 테이블을 참조해야 하는 방식과 유사합니다; IANA 시간대 데이터베이스에는 윤초 정보가 포함되어 있고, 같은 소스에서 제공되는 샘플 코드는 해당 정보를 사용하여 TAI 기반 타임스탬프와 현지 시간을 변환합니다. 변환은 역시 현재 UTC 형식의 1972년 개시되기 전에 정의상의 문제에 부딪힙니다 (아래 UTC 기준 섹션을 참조하십시오).
이 TAI-기반 시스템은, 표면적으로 유사하지만, 유닉스 시간이 아닙니다. 그것은 POSIX 시간 값과 몇 초 차이가 나는 값으로 시간을 인코딩합니다. TAI-기반 시간의 에포크가 1970-01-01T00:00:10 TAI가 아닌 1970-01-01T00:00:00 TAI인 이 시스템 버전이 ISO C의 time.h에 포함되도록 제안되었지만, 2011년에 UTC 부분만 승인되었습니다. 어쨌든 tai_clock은 C++20에 존재합니다.
Representing the number
유닉스 시간 숫자는 숫자를 나타낼 수 있는 임의의 형식에서 표현될 수 있습니다. 일부 응용 프로그램에서, 그 숫자는 단순히 텍스트적으로 십진수 문자열로 표시되어, 자명한 추가 문제만 발생시킵니다. 어쨌든, 유닉스 시간의 특정 이진 표현은 특히 중요합니다.
시간에서 한 점을 나타내는 유닉스 time_t 데이터 유형은 많은 플랫폼에서 이전 섹션에서 설명한 대로 유닉스 시간 숫자를 직접 인코딩하는 전통적으로 32비트 (그러나 아래 참조)의 부호화된 정수입니다. 32비트라는 것은 총 약 136년의 범위를 포괄한다는 의미입니다. 최소 표현 가능 날짜는 1901-12-13 금요일이고 최대 표현 가능 날짜는 2038-01-19 화요일입니다. UTC 2038-01-19 03:14:07 1초 후 이 표현은 연도 2038 문제로 알려진 것에서 오버플로됩니다.
일부 최신 운영 시스템에서는, time_t가 64비트로 확장되었습니다. 이것은 양방향으로 근사적으로 2920억 년으로 나타낼 수 있는 시간을 확장하며, 이는 한 방향당 우주의 현재 나이의 20배 이상입니다.
유닉스 time_t가 부호화되거나 부호화되지 않아야 하는지 여부에 대해 원래 약간의 논란이 있었습니다. 만약 부호화되지 않으면, 미래에서 그것의 범위가 2배가 되어, 32-비트 오버플로가 (68년까지) 지연됩니다. 어쨌든, 그것은 그런-다음 에포크 이전의 시간을 나타낼 수 없습니다. 합의는 time_t에 대해 부호화되는 것이고, 이것이 보통 관행입니다. 오래된 출시에서는 부호화된 유형을 사용했지만, QNX 운영 시스템 버전 6에 대해 소프트웨어 개발 플랫폼은 부호화되지 않은 32비트 time_t를 가집니다.
POSIX와 Open Group 유닉스 사양은 <time.h> 헤더 파일에 정의된 시간 유형과 함수를 포함하는 C 표준 라이브러리를 포함합니다. ISO C 표준에서는 time_t가 산술 유형이어야 한다고 명시하지만, 이에 대한 특정 유형이나 인코딩을 요구하지는 않습니다. POSIX는 time_t를 정수 유형이도록 요구하지만, 부호화되거나 부호화되지 않을 것을 요구하지 않습니다.
유닉스에는 정수가 아닌 유닉스 시간 숫자를 이진 분수로 직접 표현하는 전통을 가지지 않습니다. 대신, 1초 미만의 정밀도를 가진 시간은 두 개의 정수로 구성된 복합 데이터 유형을 사용하여 표현되며, 첫 번째는 time_t (유닉스 시간의 정수 부분)이고, 두 번째는 백만분의 일 (struct timeval) 또는 십억 분의 일 (struct timespec)에서 시간의 분수 부분입니다. 이들 구조는 십진수-기반 고정-점 데이터 형식을 제공하며, 이는 일부 응용 프로그램에 유용하고 다른 응용 프로그램에서는 자명하게 변환될 수 있습니다.
UTC basis
윤초를 갖는 현재 UTC의 형식은 1972년 1월 1일부터만 정의됩니다. 그 이전에는, 1961년 1월 1일부터 정수가 아닌 시간 단계가 가끔 있을 뿐만 아니라, UTC 초는 SI 초보다 약간 길었고, 주기적으로 변경되어 지속적으로 지구의 자전을 근사했던 UTC의 이전 형식이 있었습니다. 1961년 이전에는 UTC가 없었고, 1958년 이전에는 광범위한 원자 시간 기록이 없었습니다; 이들 시대에는, 원자 시간 척도 대신 GMT의 일부 근삿값 (지구의 자전을 기반으로 함)이 사용되었습니다.
UTC의 인코딩으로서 유닉스 시간의 정확한 정의는 현재의 UTC 형식에 적용될 때만 논쟁의 여지가 없습니다. 이 형식의 UTC가 시작되기 이전의 유닉스 에포크는 이 시대에서 그것의 사용에 영향을 미치지 않습니다: 1970년 1월 1일(유닉스 에포크)부터 1972년 1월 1일 (UTC의 시작)까지의 일 수는 문제가 되지 않고, 일 수는 유닉스 시간에 중요한 전부입니다.
+63072000 (즉, 1972년 1월 1일 이전) 미만의 유닉스 시간 값의 의미는 정확하게 정의되지 않습니다. 그러한 유닉스 시간의 기초는 UTC의 지정되지 않은 근사치로 가장 잘 이해됩니다. 그 시대의 컴퓨터는 어떤 경우에도 의미 있는 1초 미만의 타임스탬프를 제공할 만큼 충분히 정확하게 시계를 설정하지 않았습니다. 유닉스 시간은 1초 미만의 정밀도가 필요한 응용 프로그램에서 1972년 이전의 시간을 나타내는 적절한 방법이 아닙니다; 그러한 응용 프로그램은, 적어도, 그것들이 사용하는 UT 또는 GMT 형식을 정의해야 합니다.
2009년 기준, 표준시에서 윤초의 사용을 중단할 가능성이 고려되고 있습니다. 이 변경을 실행하는 가능한 수단은 처음에는 UTC와 일치하지만 이후에는 윤초가 없고, 따라서 TAI에서 일정한 오프셋을 유지하기 위해, 국제 시간이라고 하는 새로운 시간 스케일을 정의하여 것입니다. 이런 일이 발생하면 유닉스 시간은 UTC 대신 이 새로운 시간 스케일로 전향적으로 정의될 것입니다. 이러한 일이 발생할지 여부에 대한 불확실성으로 인해 예상 유닉스 시간은 이미 예측할 수 있습니다: UTC에 단순히 더 이상의 윤초를 가지지 않으면 그 결과는 같을 것입니다.
History
최초의 버전의 유닉스 시간은 60 Hz의 율에서 증가하는 32-비트 정수를 가졌었으며, 이는 초기 유닉스 시스템 하드웨어의 시스템 클록 속도였습니다. 값 60 Hz는 여전히 결과로 일부 소프트웨어 인터페이스에서 나타납니다. 에포크도 역시 현재 값과 달랐습니다. 1971년 11월 3일자 초판 유닉스 프로그래머의 매뉴얼은 유닉스 시간을 "1971년 1월 1일 00:00:00부터 60분의 1초로 측정한 시간"으로 정의합니다.
사용자 매뉴얼은 역시 "시간순으로 생각하는 사용자는 2**32 60분의 1초가 약 2.5년이라는 것을 알 수 있을 것"이라고 언급했습니다. 이 제한된 범위 때문에, 에포크는 그 율이 1Hz로 변경되고 에포크가 1970년 1월 1일 00:00:00 UTC의 현재 값으로 설정되기 전에 한 번 이상 재정의되었습니다. 이것은 약 136년의 범위를 산출했으며, 그것의 절반은 1970년 이전에, 절반은 이후에 이루어졌습니다.
위에 인용된 정의에서 알 수 있듯이, 유닉스 시간 스케일은 원래 에포크 이후 경과된 시간의 단순한 선형 표현으로 의도되었습니다. 어쨌든, 시간 스케일의 세부 사항에 대한 고려가 없었고, 이미 사용 가능하고 합의된 단순 선형 시간 스케일이 있다고 암묵적으로 가정했습니다. 초판 매뉴얼의 정의는 사용되는 시간대조차도 명시되어 있지 않습니다. 현재 정의의 복잡성을 포함하여 나중에 발생하는 몇 가지 문제는 유닉스 시간이 처음부터 완전히 정의되기보다는 사용법에 따라 점진적으로 정의되었기 때문입니다.
POSIX.1이 작성될 때, 윤초에 직면하여 time_t를 정확하게 정의하는 방법에 대한 질문이 일어났습니다. POSIX 위원회는 윤초 주변의 불일치를 희생하면서 표준시 또는 표준시 표현과의 변환의 복잡성을 희생하면서 유닉스 시간을 에포크 이후의 선형 초 수로 유지해야 하는지 여부를 고려했습니다. 그 시대의 컴퓨터 시계는 어떤 식으로든 선례를 만들 만큼 충분히 정확하게 설정되지 않았습니다.
POSIX 위원회는 라이브러리 기능의 복잡성에 대한 논쟁에 휘둘렸고, 유닉스 시간을 UTC 시간 요소의 관점에서 단순한 방식으로 확고히 정의했습니다. 이 정의는 너무 간단하여 그레고리력의 전체 윤년 규칙을 포함하지도 않았고, 2100년을 윤년으로 만들었습니다.
POSIX.1의 2001년 판은 유닉스 시간의 정의에서 잘못된 윤년 규칙을 수정했지만, 선형 시간 스케일이 아닌 UTC의 인코딩으로서 유닉스 시간의 본질적인 정의를 유지했습니다. 1990년대 중반 이후로 컴퓨터 시계는 일상적으로 이것이 중요하기에 충분한 정밀도로 설정되었고, 그것들은 가장 공통적으로 UTC 기반의 유닉스 시간 정의를 사용하여 설정되었습니다. 이것은 유닉스 구현과 네트워크 시간 프로토콜에서 윤초가 발생할 때마다 유닉스 시간 숫자의 단계를 실행하는 데 상당한 복잡성이 발생했습니다.
External links
- Unix Programmer's Manual, first edition
- Personal account of the POSIX decisions by Landon Curt Noll
- Clewett, James. 2,147,483,647 – The End of Time [Unix].
- chrono-Compatible Low-Level Date Algorithms – algorithms to convert between Gregorian and Julian dates and the number of days since the start of Unix time