[번역] Unix 시간은 나쁘고 교체가 필요하다

원문 링크: https://z.vandillen.dev/2022/11/21/unix-time-bad/

긱뉴스 링크: https://news.hada.io/topic?id=7898

이 번역은 현재 원저자의 명시적인 허락을 받은 상태가 아니므로, 저작권 문제 등으로 인해 추후 내용의 변경이나 게시 상태의 변화가 발생할 수 있다.

처음 정보를 접하게 된 긱뉴스 기사에 대한 존중의 의미로, 번역 제목은 긱뉴스 기사의 제목을 따랐다.

복잡한 윤초에 관한 내용을 다루는 글에 대한 내 이해를 높이기 위해 간단히 한국어로 옮겨본 것이므로, 번역의 품질에 크게 신경쓰지는 않은 상태이다.

구분선 아래부터가 번역문이고, 원문과 번역문의 문단을 번갈아 배치했다.

---

원문 게시일: November 21, 2022

A few days ago, representatives from across the world voted to abolish leap seconds from coordinated universal time, the world’s most popular time standard, on which all timezones are based (abbreviated as UTC). As it is right now, a leap second is inserted every once in a while to make sure that UTC stays synchronized with the rotation of the Earth. The universe is really quite complex, and so the exact rotation of the Earth is irregular and unpredictable to us. As a result, leap seconds are also irregular and unpredictable. Leap seconds are based upon satellite measurements and announced by the organization IERS about six months before their insertion into UTC. On average, a leap second is inserted approximately every year and a half, but this can vary by a wide margin.

며칠 전, 전 세계의 대표자들은 모든 시간대(timezone)의 기반이 되는 조정된 보편적 시간(UTC 로 약칭)에서 윤초를 제거하기로 투표를 통해서 결정 했다. 지금처럼 UTC 에는 가끔 윤초가 삽입된다. 이는 UTC와 지구의 자전을 일치시키기 위해서이다. 우주는 정말 복잡해서 지구의 자전은 우리에게 불규칙하고 예측할 수 없다. 그 결과 윤초 또한 불규칙하고 예측할 수 없다. 위성 측정에 기반하여 IERS 라는 기관에서 UTC 에 윤초를 삽입하기 6개월 전에 공지한다. 평균적으로 약 1년 반마다 윤초가 삽입되었지만, 윤초가 삽입된 시점간의 차이는 큰 편이다.

Another important time standard is international atomic time (abbreviated TAI, from the French name “temps atomique international”), a standard which is not kept in sync with the rotation of the Earth and does not have leap seconds. The difference between TAI and UTC is by definition an integer number of seconds. Since 1958 the time in TAI has drifted apart from the time based on the rotation of the Earth, leading to a difference of 37 seconds in 2022.

또다른 중요한 시간 표준은 국제 원자 시간 (약어는 TAI, 프랑스어 표현인 “temps atomique international” 에서 옴) 인데 이 표준은 지구 자전과 동기화하지 않고 있고 그래서 윤초가 없다. TAI와 UTC 의 차이는 정의상 정수초 차이다. 1958년 이후로 TAI는 지구 자전에 맞춘 시간과는 차이가 벌어져서 2022년에는 37초 차이로 벌어졌다.

The decision to get rid of leap seconds was made because of the havoc that leap seconds cause on computer systems. To put it simply, engineers expect that the timestamp of the next second is equal to the current timestamp plus one (that is, t_next == t + 1 ), but because of leap seconds, that is not true. The timestamp of the next second can be the same as the current timestamp, or it could hypothetically even be the current timestamp plus two (“hypothetically” because a leap second in this direction has not yet happened). The fact that these assumptions aren’t actually true breaks a lot of code, and in turn a lot of systems.

윤초를 제거하기로 한 결정은 컴퓨터 시스템에 윤초가 주는 큰 혼란 때문에 내려졌다. 단순하게 엔지니어는 1초 뒤의 타임스탬프는 현재 타임스탬프 더하기 1과 같다고 기대한다(즉, t_next == t + 1 ). 하지만 윤초 때문에 그것은 사실이 아니다. 다음 초의 타임스탬프는 지금 타임스탬프와 같을 수도 있고 지금 타임스탬프 더하기 2가 될 수도 있다(아직 이런 윤초가 삽입된 사례는 없지만). 엔지니어의 타임스탬프에 대한 기대가 실제로는 참이 아니라는 사실이 많은 코드와 시스템을 고장낸다.

However, the abolishment of leap seconds doesn’t mean that the problem is now solved. It still has to be decided how UTC is going to stay synchronized with the rotation of the Earth after the leap second goes away, and also whether UTC is going to stay synchronized at all. Both solutions have their downsides: If UTC becomes a linear system with no discontinuities, then it will eventually be significantly out-of-sync with the rotation of the Earth, just like TAI. On the other hand, if the leap second is replaced by a leap minute or a leap hour, then the current problems will still persist, and albeit less frequently, such problems will have a much bigger effect.

윤초를 폐지한다고 그 문제가 해결되는 것은 아니다. 윤초를 폐지한 후부터는 어떻게 UTC를 지구 자전과 동기화할 지, 그리고 UTC를 계속해서 지구 자전과 동기화할 것인지 결정을 해야 한다. 두 가지 해결책 모두 단점이 있다. UTC가 단절 없는 선형적인 시스템이 되면 결과적으로 UTC는 TAI처럼 지구 자전과는 동기화가 어긋나게 될 것이다. 반면 윤초를 윤분이나 윤시로 대체할 경우 현재의 문제는 여전히 남을 것이고 더 긴 주기로 가끔 적용을 하게됨으로써 한 번 변경할 때 더 큰 영향을 주게 될 것이다.

The point I intend to make in this article is as follows: leap seconds were not a mistake. Leap seconds in UTC are fine, because UTC was not primarily meant for engineering purposes. The mistake was, instead, to base Unix time and other computer timestamp formats on UTC instead of a strictly linear time scale. The fact that Unix time is not a linear time scale takes away a lot of mathematical properties that are crucial for its application in computers. I’ll show this in section 3. In the last section, I will discuss a proposal for changes to Unix time that would hopefully resolve this problem once and for all, completely independent of whatever might happen to UTC in the future and ideally without too much work. First, let’s talk about Unix time.

내가 이 글에서 주장하려는 것은 이렇다. 윤초는 실수가 아니었다. UTC의 윤초는 괜찮다. 왜냐하면 UTC는 엔지니어링을 위한 목적을 주로 고려한 것은 아니기 때문이다. 실수한 부분은 유닉스 시간과 그외 다른 컴퓨터 타임스탬프들이 선형적인 시간에 기반하는 대신 UTC를 기반으로 한 부분이다. 유닉스 시간이 선형적이지 않아서 컴퓨터에서 시간을 활용하는 데 중요한 수학적 특징을 포기하게 된 것이다. 섹션 3에서 이 내용을 다루겠다. 마지막 섹션에서는 이 문제를 한 번에 모두 해결할 수 있는 유닉스 시간 변경에 대해서 제안하려고 한다. 미래에 UTC에 무슨 일이 일어나든지 아무 상관이 없고 많은 작업 없이도 적용할 수 있는 제안이다. 먼저 유닉스 시간에 대해 이야기해보자.

Unix time

The simplified definition of Unix time is that Unix time counts the amount of seconds that have passed since the first of January 1970 (which is referred to as “the epoch”, similar to the first of January of 1 AD being the epoch of the Gregorian calendar). This is of course not the complete definition, since it does not take leap seconds into consideration. The exact way Unix time handles leap seconds¹ is complex and an unnecessary detail for this article, but it will suffice to say that (i) whenever a positive leap second occurs, a timestamp is used twice, and (ii) if a negative leap second were to occur, a timestamp is skipped.

유닉스 시간의 단순한 정의는 1970년 1월 1일 (“the epoch” 이라고 불리는 시간. 서기 1년 1월 1일이 그레고리안 달력을 새로 시작한 때(epoch) 인 것과 비슷함) 부터 몇 초나 흘렀는지를 나타낸다는 것이다. 물론 윤초를 고려하지 않았기 때문에 이것은 완전한 정의라고 할 수는 없다. 유닉스 시간이 윤초를 다루는 정확한 방법은² 복잡하기도 하고 여기서 다루기에는 불필요한 세부 내용이다. 여기서는 이 정도로만 이야기해도 충분할 것이다. (i) 양의 윤초가 필요할 때마다 타임스탬프는 두 번 사용되고, (ii) 음의 윤초가 필요하면 타임스탬프는 무시된다.

Besides Unix time, there is also TAI Unix time, which has no leap seconds and therefore truly counts the amount of seconds since its epoch. The epoch of TAI Unix time is January 1970 00:00:10 TAI, so ten seconds past midnight. This epoch is exactly the same moment in time as the epoch of Unix time, despite looking a little different, because the difference between UTC and TAI was ten seconds in 1970. TAI Unix time is strictly linear and has a lot of favourable mathematical properties, but is not very popular.

TAI 유닉스 시간이라는, 윤초를 가지지 않는, 그래서 epoch 로부터 흐른 시간만을 정확하게 고려하는 타임스탬프도 있다. TAI 유닉스 시간의 epoch 은 1970년 1월 1일 00:00:10 TAI 인, 자정을 10초 지난 시간이다. 이것은 유닉스 시간의 epoch 와 정확히 동일한 시점인데, 약간의 차이가 있어 보이는 건 1970년에 UTC와 TAI 사이에 10초의 차이가 있었기 때문이다. TAI 유닉스시간은 엄밀하게 선형적이고 수학적으로 더 좋은 특징을 가지고 있지만 그리 인기를 얻지는 못했다.

I’d quickly like to note that TAI Unix time is not Unix time and that TAI Unix time should always be clearly distinguished from normal Unix time. I think it’s best to compare it to bread and bread sticks. They’re both bread, they both have “bread” in the name, but when you ask a baker for bread, you don’t expect to be given bread sticks. The same applies with Unix time and TAI Unix time: When you ask for Unix time, you don’t expect to be given TAI Unix time.

여기서 바로 이야기 해두고 싶은 점은, TAI 유닉스 시간은 유닉스 시간이 아니고 TAI 시간은 보통 이야기하는 유닉스 시간과 항상 명확히 구분되어야 한다는 점이다. 이걸 빵(브레드)와 브레드 스틱에 비유하면 딱이라고 생각한다. 이 둘은 둘 다 브레드이고 이름에 “브레드”가 들어가지만 우리가 제과점에서 빵(브레드)를 달라고 할 때 브레드 스틱이 나올거라고는 생각하지 않는다. 유닉스 시간과 TAI 유닉스 시간도 마찬가지다. 우리가 유닉스 시간을 달라고 할 때 TAI 유닉스 시간을 기대하지 않는다.

I don’t mean to spoil the proposal at the end of the article, but if you’re guessing that it’s “just start using TAI Unix time”, then you’re only partially correct.

내가 제안하려는 내용을 글 끝에 가서나 보여주려는 의도는 아니다. 하지만 여기까지만 보고 내가 “TAI 유닉스 시간을 쓰자”고 제안하는 거라고 짐작한다면 그건 일부만 맞춘 것이다.

타임스탬프 기술 비교

In the table below, I compare the properties of linear timestamping techniques such as TAI Unix time to timestamping techniques with leap seconds such as Unix time. Most of the time I only mention leap seconds, but the same applies for leap minutes, leap hours or any other leaps.

TAI 유닉스 시간 같은 선형적인 타임스탬프 기술과 유닉스 시간 같이 윤초가 있는 기술을 아래 표에서 비교해두었다. 윤초에 대해서만 말하는 것 같지만, 윤분이나 윤시 혹은 다른 도약(leap)에도 동일하게 적용된다.

	Linear timestamping such as TAI Unix time	Timestamping with leap seconds (or leap minutes, or leap hours) such as Unix time
Determining the timestamp of t + 1 s	Easy	Very difficult Because the next second might be a leap second, this gets quite difficult. At the very minimum, the computer must get external information once every six months to ensure that it’s aware of the next leap second. 다음 초가 윤초일 수 있어서 결정하기 꽤 어렵다. 적어도 6개월에 한 번은 외부의 정보를 요청해서 다음 번 윤초를 알고 있어야 한다.
Determining the timestamp of t + 100000000 s	Easy	Impossible Leap seconds of the far future are not yet known, so this cannot be calculated, only estimated. 먼 미래의 윤초는 아직 알 수 없기 때문에 계산을 할 수 없다. 예측값을 구하는 정도만 가능하다.
Determining the difference between two timestamps in seconds 타임스탬프 둘의 차이가 몇 초인지 결정하기	Easy Just subtract.	Somewhat difficult Requires a look-up into a leap second table. 윤초가 기록된 표를 참조해서 계산해야 한다.
Determining the date or the time of day 타임스탬프의 날짜나 시간 구하기	Difficult We usually want to know the time in some timezone derived from UTC, and not in TAI. The timestamp must be converted to UTC first and therefore an up-to-date leap second table is required. For efficiency, it’s possible to skip the table look-up for all timestamps close to the present by keeping a few variables cached. 우리가 알고 싶은 시간은 UTC와 연관된 어느 시간대의 시간이지 TAI 기반의 시간이 아니다. 먼저 타임스탬프를 UTC로 변환해야 하므로 최신 윤초 정보가 필요하다. 현재에 가까운 값을 캐시해서 효율성을 높일 수는 있다.	Easy You can get the amount of days that have passed since the epoch by dividing a timestamp by the amount of seconds in a day (using integer division), or take the remainder of that division to get the amount of seconds since the start of the day. Those two variables can then be used to determine the date and the time of day. 타임스탬프를 하루에 해당하는 초 만큼으로 나누면 epoch 이후 며칠이나 지났는지 알 수 있다. 그 나머지를 이용하면 하루의 시작으로부터 몇 초나 지났는지 알 수 있다. 그러면 날짜와 시간을 알 수 있다.
Determining the timestamp of 2500 AD, January 1, 00:00:00 UTC or any UTC-based date in the far future	Impossible The date needs to be converted from UTC to TAI, which requires a leap second table, but leap seconds in the far future are not yet known. 주어진 시간을 UTC에서 TAI로 먼저 변환해야하고 그 때 윤초 정보가 필요하다. 그런데 먼 미래의 윤초는 아직 알 수 없다.	Easy
Ambiguous 모호성	No	Yes A timestamp of a positive leap second can refer to two moments in time. 양의 윤초에 해당하는 타임스탬프는 시간상의 두 순간을 가리키게 될 수 있다.
Has invalid values 무효인 값을 가질 수 있는지	No	Yes For each negative leap second there is an integer that is not a valid timestamp. 음의 윤초가 생기면 무효한 타임스탬프 값이 생기게 된다.

Especially the first point, about determining t + 1s, and the third point, about determining the difference, are hugely important for software internals. However, as you can see in the table, UTC-based timestamps do still have their applications. After all, UTC is what users want to see.

특히 첫 번째( t + 1s 구하기 )와 세 번째(시간차 구하기)는 소프트웨어 내부적으로 아주 중요하다. 하지만 UTC 기반의 타임스탬프는 이 두 가지를 하기에 어려운 점이 있다. 결국 사용자가 보고 싶은 건 UTC 이다.

I conclude that linear timestamping is ideal for software internals, such as storing file modification dates, networking and any kind of mathematics using timestamps, but when showing the time to the user, it should be converted to UTC. Furthermore, when the user wants the computer to remember a date in the future, such as in the case of calendar software, UTC-based timestamps are slightly better. This is because future leap seconds are not yet known, so you can only estimate the TAI-based timestamp of a UTC-based date in the far future. That estimate is likely to be a few seconds off, which can sometimes be significant (for example when code is supposed to make something happen exactly at midnight of new year’s eve, you would not want to be a few seconds off).

나는 소프트웨어 내부를 위해서는 선형적인 타임스탬프 사용이 이상적이라고 판단한다. 파일 수정 일시나 네트워크 동작, 타임스탬프로 계산해야하는 모든 작업들에 대해서다. 하지만 사용자에게 보여줄 때에는 UTC로 변환해서 보여줘야 한다. 그리고 사용자가 미래의 시점을 컴퓨터에게 기억시킬 때 (달력 소프트웨어 등)에는 UTC 기반의 타임스탬프가 조금 더 낫다. 왜냐하면 먼 미래의 윤초는 알 수 없기 때문에, UTC 기준의 미래 일시에 대한 TAI 기반 타임스탬프는 예측만 가능할 뿐이기 때문이다. 예측값은 거의 몇 초 정도의 차이겠지만 그 차이가 중요할 때도 있을 것이다(정확히 새해 첫날 0시에 뭔가 동작시켜야하는 일이라면 몇 초의 차이라도 원치 않을 것이다).

However, “just switching to TAI Unix time” would have some Y2K-esque consequences. There is a difference of 27 seconds between Unix time and TAI Unix time, and that’s also a leap in the direction that leap seconds have never gone before. Considering this, “just switching to TAI Unix time” without causing too many big incidents becomes a monumental task.

하지만 “그냥 TAI 유닉스 시간으로 바꿔버리기"를 해버리면 Y2K스러운 결과가 되어버릴 것이다. 유닉스 시간과 TAI 유닉스 시간에는 27초 차이가 있어서, 윤초 체계에서 한 번도 해보지 않은 방향의 도약이 있는 셈이다. 이 차이를 고려하면 큰 사고 없이 “그냥 TAI 유닉스 시간으로 바꿔버리기"는 엄청난 작업이 된다.

Proposal for changes to Unix time

유닉스 시간을 변경하는 방법 제안

To solve these issues without too much pain, I propose that Unix time be split into three in the POSIX standard:

너무 큰 고통 없이 이 문제를 해결하기 위해서 나는 유닉스 시간을 세 가지 POSIX 표준으로 쪼개기를 제안한다.

• UTC Unix time, which will keep tracking UTC wherever it might go in the future.
  • UTC 유닉스 시간: 미래에도 계속 UTC와의 일치를 유지할 시간
• TAI+C Unix time, which is just TAI Unix time offset by some constant amount of seconds. The constant C should be chosen so that the TAI+C Unix time will line up exactly with Unix time at the moment the transition is made from the current definition of Unix time to this proposed definition of Unix time.
  • TAI+C 유닉스 시간: TAI 유닉스 시간에 상수 C초를 더한 시간. 이 제안에 따른 전환이 적용된 시점의 유닉스 시간과 TAI+C 시간이 정확히 맞도록 하는 상수 C를 사용해야 한다.
• Legacy Unix time, which interpolates between UTC Unix time and TAI+C Unix time. Timestamps between 1970 and the year of the transition use UTC Unix time, and timestamps after the transition use TAI+C Unix time. Note that Unix time isn’t officially defined for dates before 1970.
  • 레거시 유닉스 시간: UTC 유닉스 시간과 TAI+C 유닉스 시간을 이어주는 시간. 1970년부터 이 제안의 적용 시점 사이의 타임스탬프는 UTC 유닉스 시간을 사용하고, 제안 적용 시점 이후의 타임스탬프는 TAI+C 유닉스 시간을 사용한다. 참고로 1970년 이전의 유닉스 시간은 공식적으로 정의된 적이 없다.

Any POSIX interface that’s currently returning Unix time (in UTC) should instead start returning legacy Unix time values from the date of the transition onwards.

현재 유닉스 시간(UTC 시간대로)을 리턴하는 모든 POSIX 인터페이스는 이 제안을 적용하는 시점부터 레거시 유닉스 시간을 리턴해야 한다.

In this definition, legacy Unix time is essentially the same as Unix time if no new leap seconds were ever inserted anymore. It’s not all that different from what would happen to Unix time if leap seconds were abolished altogether and never replaced. This means that, engineering-wise, this will not lead to any unexpected jumps in timestamps, and most legacy systems would not need to be changed.

이 정의에 따르면 더이상 윤초가 삽입되지 않을 경우 레거시 유닉스 시간은 본질적으로 유닉스 시간과 동일하다. 윤초가 폐지되고 전혀 교체되지 않는 경우 유닉스 시간에 일어날 일과 다르지 않다. 이 말은 엔지니어링 측면에서, 이것이 예상치 못한 타임스탬프의 점프를 일으키지 않으며, 대부분의 레거시 시스템을 변경할 필요가 없다는 의미이다.

There are engineering considerations that will still need to be decided. For example, it’s quite likely that some legacy systems depend on online resources on leap seconds such as https://www.ietf.org/timezones/data/leap-seconds.list, which provides a list of leap seconds. It would be least harmful if popular resources regarding leap seconds such as these were essentially frozen. Legacy systems that depend on resources like these likely expect Unix time and the information from the external resources to match up, so freezing these resources can prevent breakage. This means that transitioning would ideally need to be a coordinated effort.

아직 결정해야 할 엔지니어링 측면의 고려 사항이 있다. 예를 들어, 윤초 리스트를 제공하는 https://www.ietf.org/timezones/data/leap-seconds.list 같은 윤초와 관련된 온라인 리소스에 의존하는 레거시 시스템이 있을 것이다. 이런 윤초와 관련된 리소스들이 근본적으로 동결되면 가장 위험이 적을 것이다. 이런 리소스에 의존하는 레거시 시스템은 유닉스 시간과 외부 리소스로부터 얻은 정보가 일치할 것으로 기대한다. 그러므로 이런 리소스를 동결시킨다면 시스템의 중단을 막을 수 있다. 유닉스 시간의 전환을 위해서는 잘 협조된 노력이 필요하다는 의미이다.

As it is right now, leap seconds are planned to be abolished from UTC in 2035. The future of UTC after that is still uncertain, however, so some other way of adjusting the time to the rotation of the Earth may still be introduced afterwards. It would be reasonable to do the transition in 2035 so that legacy Unix time and UTC Unix time are perfectly aligned until the first time that UTC is adjusted again. That way, UTC Unix time and legacy Unix time would probably be perfectly aligned for quite a long time. Of course transitioning earlier is also possible. The main reason UTC is getting rid of leap seconds is because of the impact on software systems, and it may not even be necessary to remove leap seconds at all if software engineers themselves would simply move away from timestamping techniques that use leap seconds.

2035년에 UTC 에서 윤초는 폐지될 예정이다. 윤초가 폐지된 후의 UTC의 미래는 아직 확실치 않지만 지구의 자전과 맞추기 위한 다른 조정 방법이 이후에 도입될 수도 있다. 내가 제안하는 방식의 전환을 2035년에 적용하는 것이 합리적일 것이다. 그러면 레거시 유닉스 시간과 UTC 유닉스시간은 그 이후 처음으로 UTC를 조정하기 전까지는 완벽히 동일한 상태를 유지할 것이다. 그런 상태로 UTC 유닉스 시간과 레거시 유닉스 시간은 아마도 꽤 오랫동안 맞춰진 상태로 유지될 것이다. 물론 2035년이 아니라 더 일찍 전환을 하는 것도 가능하다. UTC에서 윤초를 제거하는 주요한 이유가 소프트웨어 시스템에 윤초가 미치는 영향 때문이므로, 만약 소프트웨어 엔지니어들 스스로가 윤초를 사용하는 타임스탬프 기술을 사용하지 않기로 결정한다면 UTC에서 윤초를 제거하는 일이 필요없게 될 수도 있다.

To summarize, the problem with the current definition of Unix time is that it does not have the mathematical properties that engineers expect it to have, which leads to software often breaking whenever a leap second is inserted. I propose to solve this problem once and for all by switching to a definition of Unix time based on TAI instead of UTC, which would lead to arithmetic using Unix time being much less error-prone.

요약하면 현재 유닉스 시간의 정의에 관한 문제는, 엔지니어들에게 필요한 수학적인 특징을 갖고 있지 못하다는 점 때문인데, 윤초를 삽입했을 때 소프트웨어의 동작에 자주 문제가 생긴다는 것이다. 나는 이 문제를 한 번에 모두 해결하기 위해서 유닉스 시간을 UTC 대신 TAI에 기반한 유닉스 시간으로 전환하기를 제안한다. 그러고나면 유닉스 시간에 대한 연산에서 오류가 날 가능성이 줄어들 것이다.

That concludes my proposal. I’ll note that my proposal here is rather informal. I’m not being paid to write this, and as such I have not taken the time to make it entirely proper and formal. If you, however, happen to be someone that does a lot of standards and specifications related work and I have piqued your interest, please feel free to turn this into a formal proposal. I have no clue where or how to submit a formal proposal myself, and honestly I also somewhat prefer to not spend my free time reading IEEE papers.

내 제안이 포멀하지 못하다고 생각한다. 유료로 기고한 글도 아니고 많은 시간을 들여서 포멀하게 가다듬지는 못했다. 하지만 누군가 내 글을 보고 흥미를 느낀 사람들 중에 표준이나 명세에 관련 있는 사람이 있다면 포멀한 제안으로 바꾸는 것은 언제든지 환영이다.

Feel free to contact me at , and thank you for reading this all the way to the end.