4년 가까운 차이는 시간대부터 고칠 문제가 아닐 수 있습니다

날짜 열을 다른 통합문서로 옮긴 뒤 연도가 몇 년 달라졌다면, 셀 서식을 다시 지정하기 전에 날짜 기준을 확인하세요. 스프레드시트의 날짜는 화면에 보이는 연·월·일과 내부 숫자가 나뉩니다. 같은 숫자라도 1900 날짜 체계와 1904 날짜 체계 중 무엇으로 읽는지에 따라 다른 날을 나타냅니다. 숫자가 손상되지 않았는데도 화면의 날짜가 달라지는 이유입니다. 원래 값에 4년을 더하는 식으로 고치면 윤일과 경계 날짜에서 설명하기 어려운 수정이 남습니다.

Microsoft가 설명하는 두 체계의 차이는 1,462일입니다. 이 글은 그 규칙을 적용해 2026년 10월 15일을 두 일련번호로 만들고, 잘못된 기준으로 읽었을 때의 결과까지 계산했습니다. 엑셀 프로그램을 열거나 실제 회사 통합문서를 옮긴 실험은 아닙니다. Python 날짜 계산과 작은 가상 OOXML 메타데이터를 사용했습니다. 따라서 특정 엑셀 버전에서 붙여넣기 시 자동 변환 여부를 확인했다는 주장은 하지 않습니다. 화면의 숫자와 기준 정보를 함께 읽는 방법을 재현하는 데 범위를 뒀습니다.

하루 정도의 차이는 날짜와 시각, 시간대가 섞인 문제일 수도 있습니다. 반면 일정한 1,462일 차이가 여러 행에서 반복된다면 날짜 체계 불일치라는 가설을 검사할 가치가 있습니다. 차이가 일정하다는 사실은 단서이며 원인 확정은 아닙니다. 비교할 때는 거래일 하나만 보지 말고, 원본에서 의미가 확인된 날짜 몇 개와 두 통합문서의 설정을 함께 대조하세요.

같은 날의 숫자 46,310과 44,848을 직접 대조했습니다

가상 기준일은 2026-10-15입니다. 실행 결과 1900 체계에서는 46,310, 1904 체계에서는 44,848이 나왔습니다. 두 수의 차이는 1,462입니다. 날짜를 문자열로 먼저 고정하고 각 체계의 규칙을 별도 함수로 계산했기 때문에, 계산 결과가 어떤 기준을 전제로 하는지 확인할 수 있습니다. 다운로드 결과에는 기준일, 두 숫자, 차이와 역변환한 날짜가 함께 들어 있습니다. 숫자만 결과 표에 남기면 다음 사람이 어느 체계로 다시 읽어야 하는지 알 수 없습니다.

입력 숫자읽는 기준실제 계산 결과
4631019002026-10-15
4484819042026-10-15
4631019042030-10-16
4484819002022-10-14

위 표에서 세 번째와 네 번째 행은 일부러 기준을 잘못 붙인 사례입니다. 46,310이라는 값이 모든 파일에서 잘못된 것은 아닙니다. 1900 체계라는 설명이 있으면 기대한 날짜를 나타냅니다. 잘못은 값과 해석 규칙의 조합에 있습니다. 수신한 숫자가 큰 쪽인지 작은 쪽인지로 옳고 그름을 판단하지 말고 원본 날짜와 기준을 함께 대조해야 합니다. 셀에 표시되는 연도만 보고 일괄 보정하면 이미 정상인 행까지 바꿀 수 있습니다.

기준은 개별 숫자보다 통합문서의 속성에 가깝습니다

XLSX를 처리하는 도구는 통합문서의 날짜 기준 정보를 읽어야 합니다. 실험에서는 workbookPr 요소에 date1904 값이 1로 설정된 작은 가상 XML을 파싱했습니다. 이는 설정값을 읽는 위치를 보여 주는 최소 예제이며, 완전한 엑셀 통합문서를 생성하거나 모든 속성 표현을 처리하는 가져오기 도구는 아닙니다. 실제 파일에서는 사용하는 라이브러리가 제공하는 날짜 기준 속성을 확인하는 편이 낫습니다. ZIP 안의 XML 한 줄만 바꾸어 정상 변환을 대신하려는 용도로 사용하지 마세요.

숫자만 CSV로 내보내면 통합문서의 속성은 그 파일에 함께 들어오지 않을 수 있습니다. 46310이라는 필드만 받아서는 날짜인지 수량인지, 날짜라면 어떤 체계인지 알 수 없습니다. CSV의 열 이름이 날짜라고 되어 있어도 기준까지 설명하지는 않습니다. 내보내기 전에 ISO 형식의 날짜 문자열로 확정할지, 숫자를 유지하고 기준을 별도 문서로 넘길지 정해야 합니다. 업무에서 날짜가 필요한 열과 단순 정수 코드 열을 나누는 이유도 여기에 있습니다.

설정을 확인할 때 현재 컴퓨터가 맥인지 윈도인지로 추측하지 않습니다. 오래된 문서의 기본값과 지금 열려 있는 문서의 실제 설정은 다를 수 있습니다. 원본이 여러 문서에서 합쳐졌다면 열 하나 안에 서로 다른 생성 경로가 섞였을 가능성도 검토하세요. 제공자가 같은 기준으로 정규화했다는 설명이 없는 한, 하나의 보정값을 모든 행에 적용하는 판단은 보류하는 편이 좋습니다.

이미 날짜 문자열로 확정된 열과 아직 일련번호인 열도 구분하세요. 2026-10-15라는 텍스트에 숫자 보정 규칙을 적용하는 것은 의미가 없습니다. 수식 결과로 나온 숫자와 원래부터 입력된 숫자도 생성 경로가 다를 수 있으므로, 셀의 현재 표시만으로 모든 열을 같은 변환 대상으로 묶지 않는 편이 좋습니다.

일련번호 60을 실제 1900년 2월 29일로 만들지 않습니다

1900 체계에는 역사적인 호환성 동작이 있습니다. Excel은 1900년을 윤년처럼 취급하지만 실제 그레고리력에서 1900년 2월 29일은 존재하지 않습니다. Microsoft 문서와 openpyxl 설명을 함께 확인한 뒤, 실험에서는 이 경계를 별도 사례로 뒀습니다. 일련번호 59는 1900-02-28, 61은 1900-03-01로 변환되지만 60은 실제 날짜로 만들지 않고 표현 불가라는 판정을 남깁니다. 실행 언어의 날짜 생성자가 예외를 내는지에만 맡기지 않고, 어떤 값이 문제인지 결과에 기록했습니다.

이런 경계에서 주변 날짜로 조용히 옮기면 후속 비교가 틀어집니다. 60을 2월 28일과 같게 처리하면 서로 다른 두 원본 값이 하나로 합쳐지고, 3월 1일로 처리하면 또 다른 중복이 됩니다. 기록 보존이 필요한 작업에서는 원래 일련번호와 원래 체계, 표현하지 못한 이유를 함께 남기는 쪽이 추적에 유리합니다. 반대로 현재 날짜만 다루는 업무에서 이 값이 나왔다면 오래된 날짜 자체보다 입력 형식이나 열 분류가 잘못됐는지 확인할 필요가 있습니다.

실험의 변환 함수는 이 경계를 설명하려고 만든 제한된 코드입니다. 음수 일련번호, 모든 오래된 파일 형식, 사용자 지정 달력까지 지원하는 범용 스프레드시트 엔진이 아닙니다. 사용 중인 라이브러리의 지원 범위와 오류 정책이 다르면 경계 결과도 다를 수 있습니다. 특히 두 도구의 출력이 다를 때는 어느 한쪽이 무조건 틀렸다고 결론 내리기보다 원래 숫자와 예외 처리 규칙을 먼저 비교하세요.

소수 부분의 시간과 날짜의 시간대는 별도입니다

같은 1900 기준에서 46310.5를 변환하자 2026-10-15T12:00:00이 나왔습니다. 이 예제에서 정수 부분은 날짜, 0.5일은 12시간입니다. 소수 부분을 제거한 뒤 날짜만 대조하면 두 행이 같아 보여도 실제로는 오전과 오후의 정보가 달랐을 수 있습니다. 날짜만 필요한 업무인지, 시각까지 보존해야 하는 업무인지 먼저 정해야 합니다. 가져오는 단계에서 임의로 정수로 바꾸는 것은 형식 정리가 아니라 정보 삭제일 수 있습니다.

이때 계산된 12시는 UTC라는 뜻이 아닙니다. 일련번호에 시간대 정보가 자동으로 들어 있다고 가정하면 안 됩니다. 원본 문서의 12시가 서울 업무 시각인지, 서버 기준 시각인지, 시간대가 없는 단순 표시인지 확인이 필요합니다. 이 글의 역변환 결과는 시간대가 붙지 않은 값입니다. 저장해야 할 것이 특정 순간이라면 별도로 시간대 계약을 적용하고, 업무상 날짜 자체라면 불필요하게 UTC 자정으로 바꾸지 않는 편이 의미를 보존합니다.

실험은 분수 0.5처럼 정확하게 확인하기 쉬운 사례를 사용했습니다. 매우 작은 소수, 여러 도구를 거친 반올림, 초보다 작은 단위의 정밀도를 모두 검증한 것은 아닙니다. 다운로드 코드에서는 초 단위로 결과를 만들므로 그보다 작은 부분은 별도 설계가 필요합니다. 결과가 같은 초로 보인다는 이유만으로 원본 숫자까지 완전히 같다고 주장하지 않습니다.

고칠 때는 원본 기준과 목적지 기준을 한 번만 대응시킵니다

기준이 다르다는 것이 확인됐다면, 원본 숫자를 원본 체계로 해석해 날짜를 얻고 목적지 형식으로 다시 표현하는 절차를 권합니다. 무조건 1,462를 더하거나 빼는 조각 코드를 여러 단계에 넣으면 이중 보정이 생길 수 있습니다. 내보내기 도구가 이미 날짜를 변환한 경우에도 추가 보정이 적용될 수 있기 때문입니다. 숫자 보정 여부와 셀 서식 변경 여부를 작업 원장에 따로 표시하면 이런 중복 작업을 찾기 쉽습니다.

검수용 표에는 원본 값, 원본 체계, 기대 날짜, 변환 날짜, 시간 부분 보존 여부를 넣을 수 있습니다. 처음에는 의미가 확실한 몇 행을 골라 기대 결과를 사람이 확인하고, 이후 전체 자료에 같은 규칙을 적용했을 때 예외가 얼마나 남는지 봅니다. 날짜가 계약 기간이나 정산 기준에 쓰인다면 통계적으로 그럴듯한 범위에 들어오는지보다 원문 기록과 맞는지가 우선입니다. 정상 범위 안의 잘못된 날짜도 충분히 생길 수 있습니다.

날짜와 시간대를 나눠 저장하는 가이드는 하루 단위로 이동하는 다른 문제를 설명합니다. 식별자처럼 보이는 숫자와 날짜 숫자가 함께 있는 파일은 숫자와 식별자 보존 기준도 같이 확인하세요. 날짜 체계의 수정으로 모든 숫자 열에 같은 처리를 적용하지 않도록 역할을 나누는 데 도움이 됩니다.

날짜 보정 전후의 증거는 표시 화면 하나보다 넓어야 합니다

서식이 적용된 화면에서는 원래 숫자가 숨겨질 수 있습니다. 검수 중에는 원본 숫자와 표시 날짜를 동시에 볼 수 있게 복사본을 준비하는 편이 좋습니다. 같은 날짜가 보인다고 두 셀의 내부 값이나 기준이 같다고 가정하지 않습니다. 반대로 숫자가 달라도 서로 다른 날짜 체계에서 같은 날짜를 뜻할 수 있습니다. 화면 비교와 값 비교를 구분하면 누가 어떤 단계에서 기준을 바꿨는지 설명하기가 쉬워집니다.

전달 문서에는 기준을 확인한 도구와 파일, 확인한 속성값, 변환 대상 열을 적으세요. 파일 전체의 날짜 기준을 바꾸는 작업과 특정 열을 문자열로 내보내는 작업은 영향 범위가 다릅니다. 다른 시트의 수식이나 연결된 표가 어떤 값을 기대하는지 모르는 상태에서 원본의 기준을 바꾸는 것은 피하고, 확인용 변환본에서 결과를 대조하세요. 이 글의 코드는 실제 문서를 수정하지 않으므로 그러한 수식 영향까지 검증하지 않습니다.

반복 가져오기를 만드는 경우에는 같은 기준이 계속 유지된다는 가정도 검사 항목으로 남길 수 있습니다. 파일 형식이나 제공 시스템이 바뀌었을 때 이전 보정 규칙을 자동 재사용하지 않고 설정을 재확인하도록 하세요. 변환 코드가 어제 성공했다는 사실은 오늘 받은 자료의 기준이 같다는 증거가 아닙니다.

결과가 맞는 날짜와 업무상 맞는 날짜는 나눠 판단합니다

이 실험이 증명한 것은 고정한 날짜와 두 체계의 숫자 대응, 잘못된 기준을 붙인 결과, 가상 윤일의 보류와 반나절 분수의 해석입니다. 실제 파일에서 원래 날짜가 올바르게 입력됐는지, 복사한 열이 정산일인지 발생일인지, 엑셀 앱의 자동 변환이 적용됐는지는 확인하지 않았습니다. 형식 변환이 정확해도 업무 원자료가 틀리면 최종 날짜는 틀릴 수 있습니다. 산술 규칙과 원문 사실을 같은 확인 칸에 합치지 마세요.

자료를 처리하기 전에 먼저 멈추는 기준을 정하면 좋습니다. 날짜 체계를 확인할 수 없거나, 원본과 비교한 표본이 1,462일 규칙으로 설명되지 않거나, 표현 불가한 값이 있다면 보정 결과를 확정하지 않습니다. 아래 결과 파일의 각 사례를 직접 대조한 뒤, 자신의 자료에서는 어떤 정보가 추가로 필요한지 적어 보세요. 값 하나를 고치는 것보다 다음 파일에서도 같은 판단을 재현할 수 있게 만드는 것이 목적입니다.

입력과 결과를 직접 대조하는 재현 자료

실험 실행일은 2026년 10월 15일이며 이 글의 발행 일정과 구분합니다. Python 3 표준 라이브러리로 가상 자료만 처리했습니다. 아래 파일은 기존 사용자 파일을 인자로 받지 않습니다.

python3 excel-1900-1904-date-systems-lab-20261015.py

실행 시각과 런타임은 환경에 따라 달라집니다. 판정 근거는 다운로드 결과의 고정 입력과 각 사례의 실제 출력으로 확인하세요.

규칙을 확인한 공식 원문

아래 원문은 2026년 10월 15일 확인했습니다. 형식과 동작의 설명을 확인한 출처이며, 이 글의 가상 실험이나 실제 업무 성과를 대신 증명하지 않습니다.