Not OT: Is Double Dating a bad thing :-)?

[CDMAP...@fortunejames.com]

In:

http://groups.google.com/group/microsoft.public.access/msg/cf857b8e3aa9c6b0

I offered a way to convert elapsed days into elapsed years/months/days
and happened to notice that I used DateAdd with the 'd' argument
instead of relying on the internal Double representation Access uses
for dates. I realize that the internal representation of dates in
Access is not going to change soon, if ever. I also realize that some
simplifications to formulae are afforded when that internal
representation is assumed. But is it good programming practice to
assume a specific internal format for dates? I think back particularly
to modular programming classes where a particular interface is
maintained while keeping the implementation details hidden so that
improvements can be made to the hidden code without aversely affecting
operational programs. I don't mean to get picky about something so
small; and I don't want the issue to become the beating of an expired
equine, but (the comma was definitely necessary there :-)) I welcome
other's thoughts on the subject.

James A. Fortune
CDMAP...@FortuneJames.com

[Lyle Fairfield]

Yes, it's a bad thing.

Dates are stored in the same boxes we use for Doubles. Some people say
they are stored as Doubles. Some people say they are Doubles. If they
were Doubles they would behave as Doubles do. They don't. (One example
is given below.)

We have Date Functions. They are clear, simple, fast. IMO they should
be used rather than direcly manipulating the numeric value of the Date.

This problem can be exacerbated when the User has a tenuous
relationship with mathematics.

****

Sub temp()
Dim d As Date
d = -(1 / 2)
Debug.Print _
" The date d is:", _
Format(d, "yyyy mm dd hh:nn:ss")
Debug.Print _
" The date d + 1 is:", _
Format(d + 1, "yyyy mm dd hh:nn:ss")
' The date d is: 1899 12 30 12:00:00
' The date d + 1 is: 1899 12 30 12:00:00
End Sub

[david epsom dot com dot au]

Double is the way dates are stored in Access and VB. In
my tests 5 years ago, using cdbl(date) was far faster
than using # ... # representations for dates.

Computers are much faster than they were even five years ago.

VB is obsolete, it has been replaced by .Net The internal
representation of dates is not the same.

SQL Server uses a different internal representation for
DateTime (long long is normally used, and there is also
a larger alternate internal representation). Jet will
convert Access dates to SQL Server Dates, but will not
always convert doubles to SQL Server Dates, leading to
off-by-one errors.

We still don't bother to use DateAdd: we use date + 1 and
when we need to add months we use our own function which
handles "30/360" dates in several different standards.

But we don't write new code using cdbl(date).

(david)

<CDMAP...@FortuneJames.com> wrote in message
news:1136507565....@g49g2000cwa.googlegroups.com...