Linux에서 운영 체제는 기본적으로 일광 절약 시간제 변경 없이 UTC 시간으로 실행되는 시계를 유지합니다.

(보통) 일광 절약 시간은 1시간으로 지정됩니다.시계를 변경하지는 않지만 표시 시 현지 시간에 적용되는 UTC 오프셋을 변경합니다..

예를 들어 중앙 유럽 시간대에서는 타임스탬프가

2024-10-27 02:59:59.999999 UTC+2  =  2024-10-27 00:59:59.999999 UTC = 1730001599

그 뒤에 타임스탬프가 표시됩니다.

2024-10-27 02:00:00.000000 UTC+1  =  2024-10-27 01:00:00.000000 UTC = 1730001600

(여기서 POSIX 시간대 지정자를 사용하지 않는다는 점에 유의하십시오. POSIX 사양의 기반이 되는 시스템은 주로 미국에서 개발되었으며 자체적으로 양의 정수 시간대 지정자를 예약했기 때문에 POSIX 시간대 오프셋의 부호는 다음과 같습니다. 당신이 생각하는 것과 다르다 반대의 기대는 UTC 오프셋에 대한 일반적인 이해를 바탕으로 합니다.

그렇기 때문에 프로그램이 타임스탬프를 현지 시간 형식으로 저장해야 한다면항상 UTC 오프셋 식별자를 포함해야 합니다.타임스탬프와 함께. 프로그램이 일광 절약 시간이 끝날 때 인간 수준의 모호성을 방지해야 하는 경우 항상 UTC에 해당하는 형식으로 내부적으로 타임스탬프를 저장해야 합니다.

---

"UTC 시간을 1초 뒤로 이동"은 시간 척도에 1초를 추가하는 것과 같습니다.이건 새로운 게 아니야, UTC 시간 표준에는 이미 이를 수행하는 표준 방법이 있습니다.윤초. 매년 6월 말과 12월 말(UTC)에 윤초를 삽입할 수 있는 기회가 있습니다.

xxxx-12-31 23:59:59 UTC

다음은

xxxx-12-31 23:59:60 UTC

그런 다음 통과

(xxxx+1)-01-01 00:00:00 UTC

이것이 실제로 일어나는지 여부는 국제기구 IERS가 결정한 지구 자전의 측정 가능한 결함에 달려 있습니다.

윤초가 마지막으로 삽입된 때는 2016년 말이었습니다.

https://hpiers.obspm.fr/eoppc/bul/bulc/UTC-TAI.history

현재로서는 2024년 6월 말에 윤초를 삽입할 계획이 없습니다. 윤초 삽입에 대한 다음 권위 있는 소스는 IERS Bulletin C입니다.

https://datacenter.iers.org/data/latestVersion/bulletinC.txt

NTP 시간 동기화 프로토콜에는 이 문제를 해결하기 위한 윤초 알림 기능이 있습니다. Linux date명령은 운영 체제가 무슨 일이 일어나고 있는지 알고 있음을 증명하기 위해 적절한 시간에 23:59:60 UTC 타임스탬프를 성실하게 표시합니다. 그러나 분명히 이는 모든 Unix 타임스탬프 초의 길이가 동일하지는 않다는 것을 의미합니다. 윤초가 삽입되기 전, 대부분의 운영 체제는 Unix 시간 초를 2초 길이로 간주합니다.

(NTP에는 "음의 윤초" 기능도 있지만 지금까지는 실제로 요구된 적이 없으며 가까운 미래에도 요구되지 않을 것으로 예상됩니다.)

새로운 대체 실용적인 솔루션은 다음과 같습니다.점프 스미어: 추가 1초는 시스템 시계 속도를 늦추어 처리되므로 추가 1초가 하루 정도 소요됩니다. 이는 초당 길이의 균일성이 +/-1초 범위의 타임스탬프 절대 정확도보다 더 중요하다는 아이디어에 기반을 두고 있습니다. 아마도 대부분의 "일반 목적" 시간 목적에 유효한 솔루션일 것입니다.

윤초는 항상 1초 미만의 타이밍 정확도나 반년 이상의 모든 시간 범위에 대한 정확한 초 계산이 필요한 사람들에게 문제가 됩니다. 그러나 이러한 정확성을 필요로 하는 대부분의 사람들은 이미 이 사실을 인지하고 대처하고 있는 것으로 밝혀졌습니다.

Linux/Unix 시스템에서 이러한 고정밀 타이밍이 필요한 경우 UTC 대신 TAI(국제 원자 시간)를 배포하기 위해 로컬 시간 동기화 기능(예: 수정된 NTP 서버)을 설정할 수 있습니다. 그런 다음 시스템 시계를 UTC 대신 TAI로 실행하고 right/IANA/Olson 시간대 데이터베이스의 시간대 변형을 사용할 수 있습니다(즉 right/Europe/Paris, Europe/Paris여기에는 윤초가 포함됩니다).

여기에는 이미 좋은 답변이 많이 있지만 더 평범한 사실에 대한 언급은 없습니다. 이 두 번째 변환이 발생합니다.항상이(가) 이미 컴퓨터에 있습니다. 때로는 이러한 변환이 1초 이상 걸릴 때도 있지만 괜찮습니다.

보시다시피, 일반 PC/서버의 하드웨어 시계는 부정확하기로 악명이 높습니다. 시계를 자주 동기화하지 않으면 전체적으로 드리프트됩니다.분연간. 출처: 가정용 컴퓨터와 서버 모두에서 이 문제를 두 번 이상 보았거나 처리해야 했습니다.

일년 내내 안정적인 시계를 만드는 것이 너무 어렵거나 비용이 많이 드는지는 모르겠지만, 내 생각에는 NTP가 간단하고 효과적인 솔루션이므로 더 정확한 하드웨어 시계가 필요하지 않을 것 같습니다. 적어도 정상적인 상황에서는 그렇지 않습니다.

그리고 – 여러분도 눈치채셨겠지만 – 우리의 모든 컴퓨터는 이것에 대해 완벽하게 괜찮습니다. 실제로 이는 컴퓨터의 시계를 수동으로 변경하는 것과 다르지 않습니다. 그런데 - 이것은 시계를 심각하게 망칠 수 있는 또 다른 작업이지만 아무런 문제도 일으키지 않습니다.

현실은 대부분의 프로그램이 시계 이동에 관심이 없다는 것입니다. 안정적인 단조로운 시계(프레임에 무엇을 그릴지 계산하는 컴퓨터 게임 등)가 필요한 경우 운영 체제에 별도의 기능이 있습니다. 타임스탬프를 반환하는 대신 "컴퓨터가 시작된 이후 나노초" 또는 이와 유사한 것을 반환합니다. 두 이벤트 사이의 경과 시간을 측정하는 데 적합합니다.

타임스탬프는 일반적으로 로깅이나 정밀도가 중요하지 않은 기타 장소에 사용됩니다. 실제 밀리초 단위의 정확한 타임스탬프가 항상 필요한 경우는 매우 드뭅니다.

다음에 추가:시계가 급격하게 뛰는 또 다른 시나리오를 기억해 보세요. 컴퓨터가 절전 모드 또는 최대 절전 모드로 전환되었다가 다시 깨어나는 경우입니다. 이제 이것은 실제로예일부 응용 프로그램에서는 이를 처리할 수 없지만, 그래도 그런 경우는 매우 드뭅니다. OS가 좋은 것 같습니다.

2를 추가하세요:핵심요약 - 윤초에 대한 OS/애플리케이션 수준 지원은 관련이 없습니다. 중요한 것은 시계 동기화 지원입니다. 컴퓨터가 외부 시간 소스와 시계를 성공적으로 동기화할 수 있는 한, 컴퓨터는 이상한 점을 알아차리지 못한 채 윤초를 선택하게 됩니다. 현재 시계 동기화는 모든 장치에서 표준이며 기본적으로 활성화되어 있습니다.

3개 추가됨:나는 이것이 결코 문제를 일으키지 않을 것이라고 말하는 것이 아닙니다. 분명히 이것은 올바른 상황에서 문제가 될 수 있습니다. 실제로 이것은 매우 드뭅니다.

다른 답변에 새로운 내용을 추가하지는 않겠지만 좀 더 간결하고 명확하게 설명하려고 노력하겠습니다.

시간대

컴퓨터의 실제 하드웨어 시계는 에포크(1970-01-01 00:00:00 UTC) 이후의 시간을 초 단위로 표시합니다. 일부 glibc 라이브러리(예:strftime(3))는 특정 시간대에서 사람이 읽을 수 있는 시간으로 변환하는 방법을 알고 있습니다.

예를 들어 미국/태평양 시간대에서는 다음 명령을 사용하여 2024년의 시간대 변경을 확인할 수 있습니다.zdump주문하다:

$ zdump -V -c 2024,2025 US/Pacific 
US/Pacific  Sun Mar 10 09:59:59 2024 UT = Sun Mar 10 01:59:59 2024 PST isdst=0 gmtoff=-28800
US/Pacific  Sun Mar 10 10:00:00 2024 UT = Sun Mar 10 03:00:00 2024 PDT isdst=1 gmtoff=-25200
US/Pacific  Sun Nov  3 08:59:59 2024 UT = Sun Nov  3 01:59:59 2024 PDT isdst=1 gmtoff=-25200
US/Pacific  Sun Nov  3 09:00:00 2024 UT = Sun Nov  3 01:00:00 2024 PST isdst=0 gmtoff=-28800

따라서 EPOCH 이후의 초 단위로 변환하려면 다음 명령을 사용할 수 있습니다.

$ date --date='Sun Mar 10 01:59:59 PST 2024' +%s
1710064799

따라서 이 특정 시간(PST)에는1710064799에포크(1970-01-01 00:00:00 UTC) 이후 경과된 시간(초)입니다.

이제 이번 초 미국/태평양 표준시를 확인하면 다음과 같은 내용이 표시됩니다.

$ TZ=US/Pacific date --date='@1710064799'
Sun Mar 10 01:59:59 PST 2024

이는 여전히 PST(태평양 표준시)입니다. 하지만 1초만 추가하면 다음과 같습니다.

$ TZ=US/Pacific date --date='@1710064800'
Sun Mar 10 03:00:00 PDT 2024

02:00부터 03:00까지 한 시간씩 "점프"하고 시간대도 PST(태평양 표준시)에서 PDT(태평양 일광 절약 시간)로 전환되는 것을 확인할 수 있습니다. 하드웨어 시계의 초는 여전히 동일한 방식으로 실행되며, 변경되는 것은 사람의 표현(특정 시간대에 따라 다름)일 뿐입니다.

윤초

처음에 시스템이 어떻게 정확한 시간을 얻습니까? NTP(네트워크 시간 동기화 프로토콜)를 사용하여 일부 시간 서버(일반적으로 라우터)에서 정확한 시간을 폴링합니다. 또한 로컬 하드웨어 시계와 시간 서버에서 폴링된 시간 사이에 차이가 있는 경우 다른 알고리즘을 사용하여 시간을 동기화합니다. 그런 다음 윤초를 추가하거나 제거하는 것이 NTP 서버의 작업입니다. 이를 수행하는 방법에는 여러 가지가 있습니다.

예를 들어,시스코 라우터, 월의 마지막 초에 윤초가 추가되거나 제거됩니다.

vl-7500-6#디스플레이 시계
2006년 12월 31일 일요일 23:59:59.123 UTC
vl-7500-6#디스플레이 시계
2006년 12월 31일 일요일 23:59:59.627 UTC
<< 59초에 2번 등장
vl-7500-6#디스플레이 시계
2006년 12월 31일 일요일 23:59:59.131 UTC    
vl-7500-6#디스플레이 시계
2006년 12월 31일 일요일 23:59:59.627 UTC

Google은점프 스미어즉, 윤초 전 마지막 날에 추가/제거된 윤초가 24시간이 끝날 때 완전히 합산될 때까지 매 초가 더 느려지거나 빨라집니다.

이 예시에서는 2022년 12월 말에 윤초를 가정했지만 실제 일정은 아직 발표되지 않았습니다.

스미어 기간은 2022-12-31 12:00:00 UTC부터 시작하여 2023-01-01 12:00:00 UTC까지 지속됩니다.. 이 기간 전후의 얼룩진 시계와 시간 서비스는 윤초를 적용한 시계와 일치합니다.

스미어 프로세스 중에는 시계가 평소보다 약간 느리게 실행됩니다. 스미어 시간 척도의 1초는 약 11.6μs 더 깁니다.육상 시간에서 SI 초 이상을 달성했습니다.

[...]

86,401 SI 초의 스미어링 동안 표시된 86,400 초의 스트레칭이 점프에 필요한 추가 SI 초에 추가됩니다.

현지 시간은 순전히 문제입니다.프리젠테이션 레이어. 이는 원격으로 최신 시스템의 Unix 시간이나 시간 데이터 모델의 일부가 아닙니다(최신 Windows에서도 하드웨어 시계를 UTC로 유지하는 것을 지원함). 즉, 이벤트는 서로에 대해 전체적으로 순서가 지정되며(윤초를 처리하는 특정 모드는 제외하고 이로 인해 어렵고 논쟁의 여지가 있음) 각 사용자(또는 각 프로세스)가 자신의 아이디어 표시 시간을 가질 수 있습니다. 시스템이 서로 다른 시간대에 있거나 단순히 다른 시간대에서 작업하거나 UTC를 사용하는 것을 선호하는 사용자가 있는지 여부에 관계없이 서로 다른 정책이 있는 시스템 간의 시간은 프레젠테이션 계층이 시간을 표시하는 방식으로 비교할 수 있습니다.