Excel VBA date bug

Question

This error was found in Excel 2010 32 bit but may be present in other versions. The error happens when writing specific dates to an Excel cell. The VBA code
Dim datDate as Date
datDate = CVDate(41586.9999999995)
ActiveWorkbook.Sheets("Sheet1").Cells(3, 2).Value=datDate
ActiveWorkbook.Sheets("Sheet1").Cells(3, 2).Value=CDbl(41586.9999999995)
Will result in the following output to the Excel sheet
11/8/2013 0:00
11/9/2013 0:00
Both dates should be 11/9/2013. The error happens when writing a date to an Excel cell when the is almost (less than a second) before midnight. The conversion of the variable from date to double precision type fixes the bug.

Answer 1

Allan wrote:
Dim datDate as Date
datDate = CVDate(41586.9999999995)
ActiveWorkbook.Sheets("Sheet1").Cells(3, 2).Value=datDate
ActiveWorkbook.Sheets("Sheet1").Cells(3, 2).Value=CDbl(41586.9999999995)
Will result in the following output to the Excel sheet
11/8/2013 0:00
11/9/2013 0:00
Both dates should be 11/9/2013.
Yes, this is a defect in the range.Value property.
You can work around it by using the range.Value2 property.  Or by not using type Date at all.
(Aha!  I stumbled upon another alternative.  See comments below about creating a column of date/times.)
I always use type Double instead of type Date because VBA sometimes does "strange" things with type Date expressions.
In the rare circumstances where VBA requires type Date, I use CDate(doubleVariable).  That does not change the internal representation of doubleVariable.
The following might help to understand the problem. [1]
Sub doit()
    Dim d As Date
    Columns("a:c").Clear
    d = Evaluate("value(""11/08/2013 23:59:59.499"")")
    Range("a1").Value = d
    Range("b1").Value2 = d
    Range("c1").Formula = "=b1"
    d = Evaluate("value(""11/08/2013 23:59:59.500"")")
    Range("a2").Value = d
    Range("b2").Value2 = d
    Range("c2").Formula = "=b2"
    Range("a1:b2").NumberFormat = "mm/dd/yyyy hh:mm:ss.000"
    Range("c1:c2").NumberFormat = "mm/dd/yyyy hh:mm"
    Columns("a:c").AutoFit
End Sub
The results are:
A1: 11/08/2013 23:59:59.000
B1: 11/08/2013 23:59:59.499
C1: 11/08/2013 23:59
A2: 11/08/2013 00:00:00.000
B2: 11/08/2013 23:59:59.500
C2: 11/09/2013 00:00
Note that C2 is correct.  So the problem is in VBA, not Excel. [2]
When VBA assigns an expression of type Date to range.Value, it rounds to the second.  (For no good reason, IMHO.)
However, VBA makes a rookie error in the rounding:  it rounds time separately, failing to add any integer carry-over to the date.
As demonstrated in C2, when formatting time as h, h:mm or h:mm:ss, Excel does round to the second.  But it does it correctly.
Allan wrote:
The value 41586.9999 is just 0.1 second short of midnight. If Excel truncated the last second instead of rounding the the date in the Excel cell should be 11/8/2013 23:59:59
I think rounding to the second (or fraction of a second indicated by the format) is the correct thing to do.
If Excel (and VBA) truncated to the second, we might have the following undesirable situation.
A1:  =VALUE("11/08/2013 23:59:59")
formatted as mm/dd/yyyy hh:mm:ss displays 11/08/2013 23:59:59
B1:  =MOD(A1,1)
formatted as hh:mm:ss displays 23:59:58 (!)
because the representation of 23:59:59 in A1 is infinitesimally smaller than the time constant 23:59:59. [3]
Allan wrote:
The error is that when using VBA code to create a column of dates by hour you sometimes get an incorrect result in the Excel cell. I fixed this issue by adding 0.1 second to the date before writing to the Excel cell.
Adding 0.1 might be adequate for your situation.  But in general, it works only by coincidence.
Allan wrote:
There are other ways to work around this bug but I think that this is the most efficient.
That depends on how you implemented the loop, which you did not share.  Based on your previous example, I assume your "efficient" implementation is something like the following:
Dim datDate as Date
datDate = 41586
For i = 1 To n
datDate = DateAdd("h", 1, datDate)
ActiveWorkbook.Sheets("Sheet1").Cells(20 + i, 2).Value = datDate + 0.1/86400
Next i
The following is probably many times faster, although you might not notice if n is very small.
Dim d0 As Date, d As Date, v(1 To n, 1 To 1) As Date
d0 = #11/8/2013#
For i = 1 To n
    ' multiply to minimize "arithmetic drift": cumulative floating-point anomalies
    d = d0 + i * TimeSerial(1, 0, 0)
    ' round to the second
    v(i, 1) = Int(d * 86400 + 0.5) / 86400
Next
ActiveWorkbook.Sheets("Sheet1").Cells(21, 2).Resize(n, 1).Value = v
Actually, the explicit rounding is probably redundant, considering the 1-hour increment.  It is probably sufficient for the loop to be:
For i = 1 To n
    ' multiply to minimize "arithmetic drift": cumulative floating-point anomalies
    v(i,1) = d0 + i * TimeSerial(1, 0, 0)
Next
As noted above, in general, it would be better to use range.Value2 instead of range.Value.
I use range.Value here to make an "aha!" point:  when "v" is an array, range.Value does not round or otherwise alter the assigned values.
[EDIT] Also, I use type Date here to minimize differences and focus on "teaching" points.  Normally, I use type Double.  No reason not to.
[1] I use Evaluate("value(""11/08/2013 23:59:59.500"")") instead of #11/08/2013 23:59:59# + 0.5/86400 because the latter is infinitesimally
less than 11/08/2013 23:59:59.500, due to floating-point arithmetic anomalies.  So it does not demonstrate the problem because VBA correctly
rounds down to 11/08/2013 23:59:59.
[2] Arguably, the problem could be in Excel's handling of the data passed from VBA, set up by the range.Value property.  But that seems unlikely since I cannot think of any reason why Excel would round to the second.  Normally, it does not unless
the cell format requires it. [EDIT] Even then, Excel rounds only for display purposes; it does not round the underlying actual value (unless the "Precision as displayed" option is set).
[3] Arguably, we should write --TEXT(MOD(A1,1),"hh:mm:ss") instead of simply MOD(A1,1), because MOD(A1,1) is not the same internal representation.  But the point remains the same:  if Excel (and VBA) truncated to the second, that would
result in 23:59:58 instead of 23:59:59 as expected.