1900년에 Excel 평일이 잘못된 이유는 무엇입니까?

1900년에 Excel 평일이 잘못된 이유는 무엇입니까?

이 질문은 다음의 관찰을 바탕으로 합니다.아담V~에그의 대답~에Excel에서 요일 이름을 셀에 어떻게 넣나요?

A1의 값이 2009-08-01이면 다음과 같습니다.

  • =WEEKDAY(A1)얻을 것이다7
  • =TEXT(7, "dddd")얻을 것이다Saturday
  • =TEXT(7,"dddd, yyyy-mm-dd")얻을 것이다Saturday, 1900-01-07
  • =TEXT(1,"dddd, yyyy-mm-dd")얻을 것이다Sunday, 1900-01-01
  • =TEXT("1900-01-01","dddd, yyyy-mm-dd")도 얻을 것이다Sunday, 1900-01-01

마지막 두 개는 틀렸습니다. 1900년 1월 1일은 실제로 월요일입니다.
다양한 출처에서 다음과 같은 사실을 확인하는 것 같습니다.

내가 무엇을 놓치고 있나요? Excel에서 이 문제가 발생하는 이유는 무엇입니까?

답변1

Microsoft에 설명된 대로KB 214058:

1900년 3월 1일 이전의 요일이 Excel에서 올바르지 않습니다.

추가 정보

Microsoft Excel의 날짜 체계는 원래 만들어졌을 때 다른 스프레드시트 프로그램에서 사용하는 날짜 체계와 완벽하게 호환되도록 설계되었습니다.

그러나 이 날짜 체계에서는 1900년이 윤년으로 잘못 해석됩니다. 1900년에는 2월 29일("윤일")이 없기 때문에 1900년 3월 1일("윤일" 다음 날) 이전 날짜의 요일이 올바르게 계산되지 않습니다.

"다른 스프레드시트 프로그램"은 다음을 참조합니다.로터스 1-2-3, 이는 당시 꽤 인기가 있었고 1900년을 윤년으로 잘못 가정했습니다. 이에 대해서는 에서 더 자세히 설명됩니다.KB 214326:

Excel 2000에서는 1900년을 윤년으로 잘못 가정합니다.

추가 정보

Lotus 1-2-3이 처음 출시되었을 때 프로그램에서는 1900년이 실제로 윤년이 아니었음에도 불구하고 윤년으로 가정했습니다. 이로 인해 프로그램에서 윤년을 더 쉽게 처리할 수 있었고 Lotus 1-2-3의 거의 모든 날짜 계산에 아무런 해를 끼치지 않았습니다.

Microsoft Multiplan과 Microsoft Excel이 출시되었을 때도 1900년을 윤년으로 가정했습니다. 이러한 가정을 통해 Microsoft Multiplan과 Microsoft Excel은 Lotus 1-2-3에서 사용하는 것과 동일한 일련 날짜 시스템을 사용하고 Lotus 1-2-3과 더 뛰어난 호환성을 제공할 수 있었습니다. 1900년을 윤년으로 처리하면 사용자가 한 프로그램에서 다른 프로그램으로 워크시트를 더 쉽게 이동할 수 있습니다.

현재 버전의 Microsoft Excel에서 1900년이 윤년이라고 가정하지 않도록 이 동작을 수정하는 것은 기술적으로 가능하지만 이렇게 하면 장점보다 단점이 더 큽니다.

이 동작을 수정하려면 다음을 포함하여 많은 문제가 발생합니다.

  • 현재 Microsoft Excel 워크시트 및 기타 문서의 거의 모든 날짜가 하루씩 단축됩니다. 이러한 변화를 수정하려면 특히 날짜를 사용하는 수식의 경우 상당한 시간과 노력이 필요합니다.
  • WEEKDAY 함수와 같은 일부 함수는 다른 값을 반환합니다. 이로 인해 워크시트의 수식이 제대로 작동하지 않을 수 있습니다.
  • 이 동작을 수정하면 Microsoft Excel과 날짜를 사용하는 다른 프로그램 간의 일련 날짜 호환성이 중단됩니다.

동작이 수정되지 않은 채 남아 있으면 한 가지 문제만 발생합니다.

  • WEEKDAY 함수는 1900년 3월 1일 이전 날짜에 대해 잘못된 값을 반환합니다. 대부분의 사용자는 1900년 3월 1일 이전 날짜를 사용하지 않기 때문에 이 문제는 거의 발생하지 않습니다.

답변2

조엘 자신이 설명하는 이유는 다음과 같습니다.나의 첫 BillG 리뷰

Basic에서는 1900년 1월 1일 대신 1899년 12월 31일을 신기원으로 사용하지만 어떤 이유에서인지 오늘 날짜는 Basic과 Excel에서도 동일했습니다.

뭐?

그 이유를 기억할 만큼 나이가 많은 엑셀 개발자를 찾아갔습니다. Ed Fries는 답을 알고 있는 것 같았습니다.

"아," 그가 나에게 말했다. "1900년 2월 28일을 확인하세요."

"59세예요." 내가 말했다.

"이제 3월 1일을 시도해 보세요."

"61이에요!"

"60은 어떻게 됐나요?" 에드가 물었다.

"2월 29일. 1900년은 윤년이었습니다! 4로 나누어떨어지죠!"

"맞는 추측이긴 한데 시가는 없어요." 에드가 말했고 나는 잠시 동안 궁금해했습니다.

이런. 나는 약간의 연구를했다. 100으로 나누어 떨어지는 해는 400으로 나누어 떨어지는 해가 아닌 이상 윤년이 아닙니다.

1900년은 윤년이 아니었습니다.

"엑셀에 버그가 있어요!" 나는 소리쳤다.

"글쎄요." 에드가 말했다. "Lotus 123 워크시트를 가져올 수 있어야 하기 때문에 그렇게 해야 했습니다."

"그럼, Lotus 123의 버그인가요?"

"그렇습니다. 하지만 아마도 의도적인 것 같습니다. Lotus는 640K에 맞아야 했습니다. 메모리가 많지는 않습니다. 1900을 무시하면 가장 오른쪽 두 비트만 봐도 해당 연도가 윤년인지 알아낼 수 있습니다. 그것은 정말 빠르고 쉬운 일입니다. 과거 두 달 동안은 틀린 것이 중요하지 않다고 생각했을 것입니다.

답변3

이에 대한 한 가지 해결책은 연도에 400년을 더하여 다음 공식과 같이 평일을 계산하는 것입니다.

=WEEKDAY(DATE(A4+400,B4,C4),1)

따라서 다음 변수는

A4 = 1834
B4 = 12
C4 = 14

12234년 12월 14일과 동일한 (일요일)을 반환합니다.
이는 1753그레고리력이 변경된 다음 해인 이전 날짜에 대해서는 작동이 중지됩니다.

관련 정보