VBA Excel 中 VBA DateValue() 中的错误？
Bug in VBA DateValue() in VBA Excel?
当我使用公式 datevalue("01/01/1900") 时，我得到 1 并将其格式化为日期，它显示为 01/01/1900
当我使用VBA
.Range("A1").Value = DateValue("01/01/1900")
它在单元格中显示为“02/01/1900”
这怎么可能？
如果我使用例如
.Range("A1").Value = DateValue("01/01/1901")
效果很好！
脑袋融化了！！！
微软声明 - "Using the default date system in Microsoft Excel for Windows, the date_text argument must represent a date between January 1, 1900 and December 31, 9999"
简而言之，Excel 的 DateTime 纪元与 VBA 的 DateTime 纪元不同。虽然，一旦你过了 1900 年 2 月 28 日，它们 是一样的。
In most modern programming environments, dates are stored as real
numbers. The integer part of the number is the number of days since
some agreed-upon date in the past, called the epoch. In Excel, today's
date, June 16, 2006, is stored as 38884, counting days where January
1st, 1900 is 1.
I started working through the various date and time functions in Basic
and the date and time functions in Excel, trying things out, when I
noticed something strange in the Visual Basic documentation: Basic
uses December 31, 1899 as the epoch instead of January 1, 1900, but
for some reason, today's date was the same in Excel as it was in
Basic.
Huh?
I went to find an Excel developer who was old enough to remember why.
Ed Fries seemed to know the answer.
"Oh," he told me. "Check out February 28th, 1900."
"It's 59," I said.
"Now try March 1st."
"It's 61!"
"What happened to 60?" Ed asked.
"February 29th. 1900 was a leap year! It's divisible by 4!"
"Good guess, but no cigar," Ed said, and left me wondering for a
while.
Oops. I did some research. Years that are divisible by 100 are not
leap years, unless they're also divisible by 400.
1900 wasn't a leap year.
"It's a bug in Excel!" I exclaimed.
"Well, not really," said Ed. "We had to do it that way because we need
to be able to import Lotus 123 worksheets."
"So, it's a bug in Lotus 123?"
"Yeah, but probably an intentional one. Lotus had to fit in 640K.
That's not a lot of memory. If you ignore 1900, you can figure out if
a given year is a leap year just by looking to see if the rightmost
two bits are zero. That's really fast and easy. The Lotus guys
probably figured it didn't matter to be wrong for those two months way
in the past. It looks like the Basic guys wanted to be anal about
those two months, so they moved the epoch one day back."
"Aargh!" I said, and went off to study why there was a checkbox in the
options dialog called 1904 Date System.
以下信息来自this Super User answer。
如 Microsoft KB 214058 中所述：
Days of the week before March 1, 1900 are incorrect in Excel
MORE INFORMATION
When the date system in Microsoft Excel was originally created, it was designed to be fully compatible with date systems used by other spreadsheet programs.
However, in this date system, the year 1900 is incorrectly interpreted as a leap year. Because there is no February 29 ("leap day") in the year 1900, the day of the week for any date before March 1, 1900 (the day after the "leap day"), is not computed correctly.
“其他电子表格程序”指的是Lotus 1-2-3, which was quite popular back then, and incorrectly assumed that year 1900 was a leap year. This is explained in even more detail in KB 214326：
Excel 2000 incorrectly assumes that the year 1900 is a leap year
MORE INFORMATION
When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year, even though it actually was not a leap year. This made it easier for the program to handle leap years and caused no harm to almost all date calculations in Lotus 1-2-3.
When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900 was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3. Treating 1900 as a leap year also made it easier for users to move worksheets from one program to the other.
Although it is technically possible to correct this behavior so that current versions of Microsoft Excel do not assume that 1900 is a leap year, the disadvantages of doing so outweigh the advantages.
If this behavior were to be corrected, many problems would arise, including the following:
- Almost all dates in current Microsoft Excel worksheets and other documents would be decreased by one day. Correcting this shift would take considerable time and effort, especially in formulas that use dates.
- Some functions, such as the WEEKDAY function, would return different values; this might cause formulas in worksheets to work incorrectly.
- Correcting this behavior would break serial date compatibility between Microsoft Excel and other programs that use dates.
If the behavior remains uncorrected, only one problem occurs:
- The WEEKDAY function returns incorrect values for dates before March 1, 1900. Because most users do not use dates before March 1, 1900, this problem is rare.
当我使用公式 datevalue("01/01/1900") 时，我得到 1 并将其格式化为日期，它显示为 01/01/1900
当我使用VBA
.Range("A1").Value = DateValue("01/01/1900")
它在单元格中显示为“02/01/1900”
这怎么可能？
如果我使用例如
.Range("A1").Value = DateValue("01/01/1901")
效果很好！
脑袋融化了！！！
微软声明 - "Using the default date system in Microsoft Excel for Windows, the date_text argument must represent a date between January 1, 1900 and December 31, 9999"
简而言之，Excel 的 DateTime 纪元与 VBA 的 DateTime 纪元不同。虽然，一旦你过了 1900 年 2 月 28 日，它们 是一样的。
In most modern programming environments, dates are stored as real numbers. The integer part of the number is the number of days since some agreed-upon date in the past, called the epoch. In Excel, today's date, June 16, 2006, is stored as 38884, counting days where January 1st, 1900 is 1.
I started working through the various date and time functions in Basic and the date and time functions in Excel, trying things out, when I noticed something strange in the Visual Basic documentation: Basic uses December 31, 1899 as the epoch instead of January 1, 1900, but for some reason, today's date was the same in Excel as it was in Basic.
Huh?
I went to find an Excel developer who was old enough to remember why. Ed Fries seemed to know the answer.
"Oh," he told me. "Check out February 28th, 1900."
"It's 59," I said.
"Now try March 1st."
"It's 61!"
"What happened to 60?" Ed asked.
"February 29th. 1900 was a leap year! It's divisible by 4!"
"Good guess, but no cigar," Ed said, and left me wondering for a while.
Oops. I did some research. Years that are divisible by 100 are not leap years, unless they're also divisible by 400.
1900 wasn't a leap year.
"It's a bug in Excel!" I exclaimed.
"Well, not really," said Ed. "We had to do it that way because we need to be able to import Lotus 123 worksheets."
"So, it's a bug in Lotus 123?"
"Yeah, but probably an intentional one. Lotus had to fit in 640K. That's not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That's really fast and easy. The Lotus guys probably figured it didn't matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months, so they moved the epoch one day back."
"Aargh!" I said, and went off to study why there was a checkbox in the options dialog called 1904 Date System.
以下信息来自this Super User answer。
如 Microsoft KB 214058 中所述：
Days of the week before March 1, 1900 are incorrect in Excel
MORE INFORMATION
When the date system in Microsoft Excel was originally created, it was designed to be fully compatible with date systems used by other spreadsheet programs.
However, in this date system, the year 1900 is incorrectly interpreted as a leap year. Because there is no February 29 ("leap day") in the year 1900, the day of the week for any date before March 1, 1900 (the day after the "leap day"), is not computed correctly.
“其他电子表格程序”指的是Lotus 1-2-3, which was quite popular back then, and incorrectly assumed that year 1900 was a leap year. This is explained in even more detail in KB 214326：
Excel 2000 incorrectly assumes that the year 1900 is a leap year
MORE INFORMATION
When Lotus 1-2-3 was first released, the program assumed that the year 1900 was a leap year, even though it actually was not a leap year. This made it easier for the program to handle leap years and caused no harm to almost all date calculations in Lotus 1-2-3.
When Microsoft Multiplan and Microsoft Excel were released, they also assumed that 1900 was a leap year. This assumption allowed Microsoft Multiplan and Microsoft Excel to use the same serial date system used by Lotus 1-2-3 and provide greater compatibility with Lotus 1-2-3. Treating 1900 as a leap year also made it easier for users to move worksheets from one program to the other.
Although it is technically possible to correct this behavior so that current versions of Microsoft Excel do not assume that 1900 is a leap year, the disadvantages of doing so outweigh the advantages.
If this behavior were to be corrected, many problems would arise, including the following:
- Almost all dates in current Microsoft Excel worksheets and other documents would be decreased by one day. Correcting this shift would take considerable time and effort, especially in formulas that use dates.
- Some functions, such as the WEEKDAY function, would return different values; this might cause formulas in worksheets to work incorrectly.
- Correcting this behavior would break serial date compatibility between Microsoft Excel and other programs that use dates.
If the behavior remains uncorrected, only one problem occurs:
- The WEEKDAY function returns incorrect values for dates before March 1, 1900. Because most users do not use dates before March 1, 1900, this problem is rare.